From dmuysers at hotmail.com Sat May 25 16:49:52 2019 From: dmuysers at hotmail.com (dirk muysers) Date: Sat, 25 May 2019 14:49:52 +0000 Subject: [M3devel] Impossible to compile to recent Windows versions Message-ID: My configuration: PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD PROCESSOR_LEVEL=21 PROCESSOR_REVISION=1001 running Windows 7 Pro I am using M3 release "cm3-min-x86-d5.10.0-VC2015-20160102" After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019 I then edited "NT.common" in bin/config: ----- Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end ----- and I still get: Microsoft (R) Incremental Linker Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:Maketables.exe -subsystem:console -entry:mainCRTStartup -nodefaultlib -debug -incremental:no -opt:ref -delayload:ws2_32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll -delayload:rpcrt4.dll -delayload:iphlpapid.dll delayimp.lib _m3main.obj Main.mo Common.io Common.mo Loader.io Loader.mo Editor.io Editor.mo Printer.io Printer.mo C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa iphlpapi.lib rpcrt4.lib winspool.lib comctl32.lib ws2_32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits. If anybody has an idea... Otherwise I can't use M3 anymore. Am I the only one using Windows? -------------- next part -------------- An HTML attachment was scrubbed... URL: From RColeburn at comcast.net Sat May 25 23:42:57 2019 From: RColeburn at comcast.net (Randy Coleburn) Date: Sat, 25 May 2019 17:42:57 -0400 Subject: [M3devel] Impossible to compile to recent Windows versions In-Reply-To: References: Message-ID: <035701d51342$d1ed5960$75c80c20$@comcast.net> I too can?t make Windows work anymore. I can get some stuff to compile, but not everything. --Randy Coleburn From: M3devel On Behalf Of dirk muysers Sent: Saturday, May 25, 2019 10:50 AM To: m3devel at elegosoft.com Subject: [M3devel] Impossible to compile to recent Windows versions My configuration: PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD PROCESSOR_LEVEL=21 PROCESSOR_REVISION=1001 running Windows 7 Pro I am using M3 release "cm3-min-x86-d5.10.0-VC2015-20160102" After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019 I then edited "NT.common" in bin/config: ----- Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools " VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702 " DevEnvDir = Msdev & "\\Common7\\\IDE " end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86 " VCLib = VCInstallDir & "\\lib " VCInc = VCInstallDir & "\\include " end ----- and I still get: Microsoft (R) Incremental Linker Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:Maketables.exe -subsystem:console -entry:mainCRTStartup -nodefaultlib -debug -incremental:no -opt:ref -delayload:ws2_32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll -delayload:rpcrt4.dll -delayload:iphlpapid.dll delayimp.lib _m3main.obj Main.mo Common.io Common.mo Loader.io Loader.mo Editor.io Editor.mo Printer.io Printer.mo C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa iphlpapi.lib rpcrt4.lib winspool.lib comctl32.lib ws2_32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits. If anybody has an idea... Otherwise I can't use M3 anymore. Am I the only one using Windows? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun May 26 09:20:48 2019 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 26 May 2019 17:20:48 +1000 Subject: [M3devel] Impossible to compile to recent Windows versions In-Reply-To: <035701d51342$d1ed5960$75c80c20$@comcast.net> References: <035701d51342$d1ed5960$75c80c20$@comcast.net> Message-ID: Assuming you have the 32 bit environment setup via vcvars32.bat or the newer vcvarsall.bat. That error suggests you're trying to build a 32 bit program with a 64 bit linker and libraries. I can still compile m3 programs except I cant link in dll's - maybe Jay could suggest a fix there. Regards Peter On Sun, May 26, 2019 at 7:43 AM Randy Coleburn wrote: > I too can?t make Windows work anymore. > > I can get some stuff to compile, but not everything. > > --Randy Coleburn > > > > *From:* M3devel *On Behalf Of *dirk > muysers > *Sent:* Saturday, May 25, 2019 10:50 AM > *To:* m3devel at elegosoft.com > *Subject:* [M3devel] Impossible to compile to recent Windows versions > > > > My configuration: > > PROCESSOR_ARCHITECTURE=AMD64 > > PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD > > PROCESSOR_LEVEL=21 > > PROCESSOR_REVISION=1001 > > running Windows 7 Pro > > > > I am using M3 release "cm3-min-x86-d5.10.0-VC2015-20160102" > > > > After struggling a lot I removed Visual Studio 10 (which I never use as > such) and installed Microsoft Build Tools 2019 > > I then edited "NT.common" in bin/config: > > ----- > > Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual > Studio\\2019\\BuildTools" > > VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" > > DevEnvDir = Msdev & "\\Common7\\\IDE" > > end end end end > > if VCInstallDir > > VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" > > VCLib = VCInstallDir & "\\lib" > > VCInc = VCInstallDir & "\\include" > > end > > ----- > > and I still get: > > > > Microsoft (R) Incremental Linker Version 10.00.30319.01 > > Copyright (C) Microsoft Corporation. All rights reserved. > > -out:Maketables.exe > > -subsystem:console > > -entry:mainCRTStartup > > -nodefaultlib > > -debug > > -incremental:no > > -opt:ref > > -delayload:ws2_32.dll > > -delayload:advapi32.dll > > -delayload:gdi32.dll > > -delayload:netapi32.dll > > -delayload:user32.dll > > -delayload:comctl32.dll > > -delayload:rpcrt4.dll > > -delayload:iphlpapid.dll > > delayimp.lib > > _m3main.obj > > Main.mo > > Common.io > > Common.mo > > Loader.io > > Loader.mo > > Editor.io > > Editor.mo > > Printer.io > > Printer.mo > > C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa > > C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa > > iphlpapi.lib > > rpcrt4.lib > > winspool.lib > > comctl32.lib > > ws2_32.lib > > comdlg32.lib > > netapi32.lib > > gdi32.lib > > user32.lib > > advapi32.lib > > kernel32.lib > > msvcrt.lib > > Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with > target machine type 'x64' > > > > After trying everything, worming my way through the configuration > labyrinth, I am at the end of my wits. > > If anybody has an idea... > > Otherwise I can't use M3 anymore. > > Am I the only one using Windows? > _______________________________________________ > 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 Sun May 26 13:07:11 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 11:07:11 +0000 Subject: [M3devel] Impossible to compile to recent Windows versions In-Reply-To: References: <035701d51342$d1ed5960$75c80c20$@comcast.net>, Message-ID: install pyhon (2.7) e.g. to c:\python2.7? ? download and extract? http://www.opencm3.net/releng/cm3-bin-min-NT386-5.8.6-REL.tgz? You get system.tgz? Extract that.? ? Do not run the installer or update the .cfg.? I never liked the installer and I wrote .cfg files? that try to adapt to the environment and multiple releases of cm3 (try an older one? ?) Put it in e.g.? c:\cm3\bin\cm3.exe? ? git clone current cm3? ? run developer command prompt? verify cl.exe runs and says ..x86? ? put python in path:? path=C:\Python27;%path%? ? go into git clone:? cd C:\s\cm3\scripts\python? ? install latest config files: python install-config.py? ? ? apply very small change for newer compiler: https://github.com/modula3/cm3/pull/48? ? python upgrade.py? ? or rather, look at upgrade-full.cmd:? python upgrade.py? python do-cm3-all.py realclean skipgcc? python do-cm3-all.py buildship? ? At least upgrade.py worked for me.? I'm doing the rest.? ? Now to fix some things. :)? hm: ..\src\FastNumParse.m3", line 3: warning: not used (Fmt) 2 warnings encountered? new source -> compiling printf.c? new source -> compiling getloadavg_glue.c? new source -> compiling diskAvail.c? cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\diskAvail.c -FodiskAvail.obj? diskAvail.c? ..\\src\\diskAvail.c(5): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory? compile_c => 2? C compiler failed compiling: ..\src\diskAvail.c? new source -> compiling CTZ.c? new source -> compiling UtimeOpsC.c? cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\UtimeOpsC.c -FoUtimeOpsC.obj? UtimeOpsC.c? ..\\src\\UtimeOpsC.c(62): error C2039: 'tm_gmtoff': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(62): warning C4033: 'UtimeOpsC__Get_gmtoff' must return a value? ..\\src\\UtimeOpsC.c(75): error C2039: 'tm_zone': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(75): warning C4033: 'UtimeOpsC__Get_zone' must return a value? ..\\src\\UtimeOpsC.c(123): error C2039: 'tm_gmtoff': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(134): warning C4047: 'initializing': 'tm *' differs in levels of indirection from 'int'? ..\\src\\UtimeOpsC.c(158): warning C4047: 'return': 'char *' differs in levels of indirection from 'int'? compile_c => 2? C compiler failed compiling: ..\src\UtimeOpsC.c? new exporters -> recompiling Debug.i3? new exporters -> recompiling TextUtils.i3? new exporters -> recompiling RTBrand.i3? new exporters -> recompiling RefRecord.i3? new exporters -> recompiling SchedulerIndirection.i3? new exporters -> recompiling FileSharing.i3? new exporters -> recompiling TZ.i3? new exporters -> recompiling HMTime.i3? compilation failed => not building library "cit_util.lib"? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay ________________________________ From: M3devel on behalf of Peter McKinna Sent: Sunday, May 26, 2019 7:20 AM To: Randy Coleburn Cc: m3devel Subject: Re: [M3devel] Impossible to compile to recent Windows versions Assuming you have the 32 bit environment setup via vcvars32.bat or the newer vcvarsall.bat. That error suggests you're trying to build a 32 bit program with a 64 bit linker and libraries. I can still compile m3 programs except I cant link in dll's - maybe Jay could suggest a fix there. Regards Peter On Sun, May 26, 2019 at 7:43 AM Randy Coleburn > wrote: I too can?t make Windows work anymore. I can get some stuff to compile, but not everything. --Randy Coleburn From: M3devel > On Behalf Of dirk muysers Sent: Saturday, May 25, 2019 10:50 AM To: m3devel at elegosoft.com Subject: [M3devel] Impossible to compile to recent Windows versions My configuration: PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD PROCESSOR_LEVEL=21 PROCESSOR_REVISION=1001 running Windows 7 Pro I am using M3 release "cm3-min-x86-d5.10.0-VC2015-20160102" After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019 I then edited "NT.common" in bin/config: ----- Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end ----- and I still get: Microsoft (R) Incremental Linker Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:Maketables.exe -subsystem:console -entry:mainCRTStartup -nodefaultlib -debug -incremental:no -opt:ref -delayload:ws2_32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll -delayload:rpcrt4.dll -delayload:iphlpapid.dll delayimp.lib _m3main.obj Main.mo Common.io Common.mo Loader.io Loader.mo Editor.io Editor.mo Printer.io Printer.mo C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa iphlpapi.lib rpcrt4.lib winspool.lib comctl32.lib ws2_32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits. If anybody has an idea... Otherwise I can't use M3 anymore. Am I the only one using Windows? _______________________________________________ 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 Sun May 26 14:27:52 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 12:27:52 +0000 Subject: [M3devel] Impossible to compile to recent Windows versions In-Reply-To: References: <035701d51342$d1ed5960$75c80c20$@comcast.net>, , Message-ID: https://github.com/modula3/cm3/pull/50 https://github.com/modula3/cm3/pull/48 hopefully more soon.. - Jay ________________________________ From: Jay K Sent: Sunday, May 26, 2019 11:07 AM To: Peter McKinna; Randy Coleburn Cc: m3devel Subject: Re: [M3devel] Impossible to compile to recent Windows versions install pyhon (2.7) e.g. to c:\python2.7? ? download and extract? http://www.opencm3.net/releng/cm3-bin-min-NT386-5.8.6-REL.tgz? You get system.tgz? Extract that.? ? Do not run the installer or update the .cfg.? I never liked the installer and I wrote .cfg files? that try to adapt to the environment and multiple releases of cm3 (try an older one? ?) Put it in e.g.? c:\cm3\bin\cm3.exe? ? git clone current cm3? ? run developer command prompt? verify cl.exe runs and says ..x86? ? put python in path:? path=C:\Python27;%path%? ? go into git clone:? cd C:\s\cm3\scripts\python? ? install latest config files: python install-config.py? ? ? apply very small change for newer compiler: https://github.com/modula3/cm3/pull/48? ? python upgrade.py? ? or rather, look at upgrade-full.cmd:? python upgrade.py? python do-cm3-all.py realclean skipgcc? python do-cm3-all.py buildship? ? At least upgrade.py worked for me.? I'm doing the rest.? ? Now to fix some things. :)? hm: ..\src\FastNumParse.m3", line 3: warning: not used (Fmt) 2 warnings encountered? new source -> compiling printf.c? new source -> compiling getloadavg_glue.c? new source -> compiling diskAvail.c? cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\diskAvail.c -FodiskAvail.obj? diskAvail.c? ..\\src\\diskAvail.c(5): fatal error C1083: Cannot open include file: 'sys/param.h': No such file or directory? compile_c => 2? C compiler failed compiling: ..\src\diskAvail.c? new source -> compiling CTZ.c? new source -> compiling UtimeOpsC.c? cl.exe -nologo -DWIN32 -Zl -Ic:/cm3/pkg/m3core/src/unix/Common -Ic:/cm3/pkg/m3core/src -Ic:/cm3/pkg/m3core/src/Csupport/Common -Ic:/cm3/pkg/m3core/src/Csupport/little-endian -Ic:/cm3/pkg/m3core/src/Csupport/libgcc -Ic:/cm3/pkg/m3core/src/runtime/common -Ic:/cm3/pkg/m3core/src/runtime/WIN32 -Ic:/cm3/pkg/m3core/src/runtime/ex_frame -Ic:/cm3/pkg/m3core/src/thread/Common -Ic:/cm3/pkg/m3core/src/thread/WIN32 -Ic:/cm3/pkg/m3core/src/win32 -Ic:/cm3/pkg/m3core/src/C/Common -Ic:/cm3/pkg/m3core/src/time/WIN32 -Ic:/cm3/pkg/libm3/src/uid/WIN32 -Ic:/cm3/pkg/patternmatching/src/libglob -I../src -Z7 -MD -Ox -Oi -c ..\\src\\UtimeOpsC.c -FoUtimeOpsC.obj? UtimeOpsC.c? ..\\src\\UtimeOpsC.c(62): error C2039: 'tm_gmtoff': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(62): warning C4033: 'UtimeOpsC__Get_gmtoff' must return a value? ..\\src\\UtimeOpsC.c(75): error C2039: 'tm_zone': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(75): warning C4033: 'UtimeOpsC__Get_zone' must return a value? ..\\src\\UtimeOpsC.c(123): error C2039: 'tm_gmtoff': is not a member of 'tm'? C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_wtime.h(22): note: see declaration of 'tm'? ..\\src\\UtimeOpsC.c(134): warning C4047: 'initializing': 'tm *' differs in levels of indirection from 'int'? ..\\src\\UtimeOpsC.c(158): warning C4047: 'return': 'char *' differs in levels of indirection from 'int'? compile_c => 2? C compiler failed compiling: ..\src\UtimeOpsC.c? new exporters -> recompiling Debug.i3? new exporters -> recompiling TextUtils.i3? new exporters -> recompiling RTBrand.i3? new exporters -> recompiling RefRecord.i3? new exporters -> recompiling SchedulerIndirection.i3? new exporters -> recompiling FileSharing.i3? new exporters -> recompiling TZ.i3? new exporters -> recompiling HMTime.i3? compilation failed => not building library "cit_util.lib"? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay ________________________________ From: M3devel on behalf of Peter McKinna Sent: Sunday, May 26, 2019 7:20 AM To: Randy Coleburn Cc: m3devel Subject: Re: [M3devel] Impossible to compile to recent Windows versions Assuming you have the 32 bit environment setup via vcvars32.bat or the newer vcvarsall.bat. That error suggests you're trying to build a 32 bit program with a 64 bit linker and libraries. I can still compile m3 programs except I cant link in dll's - maybe Jay could suggest a fix there. Regards Peter On Sun, May 26, 2019 at 7:43 AM Randy Coleburn > wrote: I too can?t make Windows work anymore. I can get some stuff to compile, but not everything. --Randy Coleburn From: M3devel > On Behalf Of dirk muysers Sent: Saturday, May 25, 2019 10:50 AM To: m3devel at elegosoft.com Subject: [M3devel] Impossible to compile to recent Windows versions My configuration: PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 16 Stepping 1, AuthenticAMD PROCESSOR_LEVEL=21 PROCESSOR_REVISION=1001 running Windows 7 Pro I am using M3 release "cm3-min-x86-d5.10.0-VC2015-20160102" After struggling a lot I removed Visual Studio 10 (which I never use as such) and installed Microsoft Build Tools 2019 I then edited "NT.common" in bin/config: ----- Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end ----- and I still get: Microsoft (R) Incremental Linker Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:Maketables.exe -subsystem:console -entry:mainCRTStartup -nodefaultlib -debug -incremental:no -opt:ref -delayload:ws2_32.dll -delayload:advapi32.dll -delayload:gdi32.dll -delayload:netapi32.dll -delayload:user32.dll -delayload:comctl32.dll -delayload:rpcrt4.dll -delayload:iphlpapid.dll delayimp.lib _m3main.obj Main.mo Common.io Common.mo Loader.io Loader.mo Editor.io Editor.mo Printer.io Printer.mo C:\Users\Public\programs\cm3\pkg\libm3\NT386\m3.lib.sa C:\Users\Public\programs\cm3\pkg\m3core\NT386\m3core.lib.sa iphlpapi.lib rpcrt4.lib winspool.lib comctl32.lib ws2_32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib Main.mo : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' After trying everything, worming my way through the configuration labyrinth, I am at the end of my wits. If anybody has an idea... Otherwise I can't use M3 anymore. Am I the only one using Windows? _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Sun May 26 14:45:58 2019 From: dmuysers at hotmail.com (dirk muysers) Date: Sun, 26 May 2019 12:45:58 +0000 Subject: [M3devel] Windows with MS BuildTool Message-ID: The problem is: Since I never use Visual Studio per se, I unistalled the whole thing and replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as follows: -------------- % Msdev = SystemDrive & "\\msdev\\80" Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end --------------------- The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32, and, for both of them, targets x64 and x86. I thus compiled using Host64, target x86 and still get the bloody LNK1112 error! And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Sun May 26 16:55:58 2019 From: vvm at tut.by (vvm at tut.by) Date: Sun, 26 May 2019 17:55:58 +0300 Subject: [M3devel] Modula-3 for Windows x64 Message-ID: <12849991558882558@iva6-62cf6ab2a3cd.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 19:55:59 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 17:55:59 +0000 Subject: [M3devel] Windows with MS BuildTool In-Reply-To: References: Message-ID: Ideally if cl.exe and link.exe are already in PATH and LIB is already set, we don't have to run any of that. I'll have to install 2019 and see. - Jay ________________________________ From: M3devel on behalf of dirk muysers Sent: Sunday, May 26, 2019 12:45 PM To: m3devel at elegosoft.com Subject: [M3devel] Windows with MS BuildTool The problem is: Since I never use Visual Studio per se, I unistalled the whole thing and replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as follows: -------------- % Msdev = SystemDrive & "\\msdev\\80" Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end --------------------- The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32, and, for both of them, targets x64 and x86. I thus compiled using Host64, target x86 and still get the bloody LNK1112 error! And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 20:11:54 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 18:11:54 +0000 Subject: [M3devel] integer types? Message-ID: This may be repeat topic. I think I had tried this before and ran into problems, but:? ? INTERFACE BasicCtypes;? ? (* the four signed integer types *)? signed_char = [-16_7f-1 .. 16_7f];? short_int = [-16_7fff-1 .. 16_7fff];? int = [-16_7fffffff-1 .. 16_7fffffff];? unsigned_char = [16_0 .. 16_ff];? unsigned_short_int = [16_0 .. 16_ffff];? ? ? seems like it should be: ? (* the four signed integer types *)? signed_char = BITS 8 FOR [-16_7f-1 .. 16_7f];? short_int = BITS 16 FOR [-16_7fff-1 .. 16_7fff];? int = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];? unsigned_char = BITS 8 [16_0 .. 16_ff];? unsigned_short_int = BITS 16 [16_0 .. 16_ffff];? ? and then really, worse:? ? unsigned_int = Word.T;? looks wrong in multiple ways. ? imagine passing this as VAR to C for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 20:57:11 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 18:57:11 +0000 Subject: [M3devel] Windows with MS BuildTool In-Reply-To: References: Message-ID: I just ran "developer command prompt for VS 2019" and gives me: C:\>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86? usage: cl [ option... ] filename... [ /link linkoption... ]? ? C:\>where cl.exe? C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx86\x86\cl.exe? I'll update pylib.py to mape 19.2 to 2019. Perhaps we should just preprocess _MSC_VER and use that though. C:\s>echo _MSC_VER >1.c? ? C:\s>cl -EP 1.c? Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86? 1.c? ? 1921? This is on an amd64 system which is all anyone uses these days. This version is used to stamp into distribution archive names, which is a rare use-case. And we need to know if it is 2015 or newer, to guide linking, which we can either default or I can try to detect otherwise, or I can revisit, maybe we don't care. We have our own build system and such, you know. I'd kinda like to generate cmake or automake files instead. That'd help the Unix distribution/setup story. I know nobody likes automake and perhaps cmake, but nobody likes to maintain their own either, I think. - Jay ________________________________ From: M3devel on behalf of dirk muysers Sent: Sunday, May 26, 2019 12:45 PM To: m3devel at elegosoft.com Subject: [M3devel] Windows with MS BuildTool The problem is: Since I never use Visual Studio per se, I unistalled the whole thing and replaced it with the Visual Studio 2019 BuildTool, modifying "NT.common" as follows: -------------- % Msdev = SystemDrive & "\\msdev\\80" Msdev = SystemDrive & "\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools" VCInstallDir = Msdev & "\\VC\\Tools\\MSVC\\14.21.27702" DevEnvDir = Msdev & "\\Common7\\\IDE" end end end end if VCInstallDir VCBin = VCInstallDir & "\\bin\\Hostx64\\x86" VCLib = VCInstallDir & "\\lib" VCInc = VCInstallDir & "\\include" end --------------------- The MS 2019 build tool, has four sets of executables. Under "bin" two directories Host64 and Host32, and, for both of them, targets x64 and x86. I thus compiled using Host64, target x86 and still get the bloody LNK1112 error! And trying to follow what happens through the umpteen Russian Doll config files is near impossible for someone who did not participate in the setting-up of the whole thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 22:38:16 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 20:38:16 +0000 Subject: [M3devel] CI for modula-3 Message-ID: Presumably we should have some CI? Something free as in beer? Travis? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 23:13:35 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 21:13:35 +0000 Subject: [M3devel] -boot and C backend broken by LLVM? Message-ID: I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot. This is e.g. how you start with AMD64_NT. Well, other than an existing distribution. The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful. I'll try to fix it. I find the builder to be a bit of spaghetti code but maybe I just lack context. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 23:26:04 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 21:26:04 +0000 Subject: [M3devel] meaning of cm3 -boot? Message-ID: I think the term "bootstrap" maybe is too vague. ? There are various pipelines, like:? ? Gcc-based backend:? .m3 => .mc => .s/.o => link? ? Integrated backend:? .m3 => .o => link? ? C backend:? .m3 => .m3.c => s/.o => link? ? ? "boot" means, stop at some point, and run the rest later.? ? Just because, cross tools might be less available than native tools,? such as when crossing from Unix to Windows,? or we might want to redistribute intermediate files in order? to have an install w/o cm3, but w/ C compiler or assembler? ? Maybe it'd be better to have flags like:? -stop-at-c (run C compiler and linker later) ? -stop-at-s (run assembly and linker linker) ? -stop-at-o (run link later) ? ? Note that this is confusing too, because each pipeline? outputs multiple possible formats, so has multiple possible? stopping points.? ? i.e. A backend might output assembly or .o? ? In the "original" 3.6 era, -boot meant to stop at .s and c.? ? Perhaps that is approximately ideal, i.e. to at least stop? at text files, for which many tools exist, and not "binary" files,? even if the .s/.c might be "derived", as the .s were back then.? In the presence of decent cross assembly/Ccompiler/linker, unless forming redistributable text files, this isn't needed. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 26 23:43:16 2019 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 May 2019 21:43:16 +0000 Subject: [M3devel] -boot and C backend broken by LLVM? In-Reply-To: References: Message-ID: I think in particular PushOneM3 got replaced. ? I'll keep looking at it.. ________________________________ From: Jay K Sent: Sunday, May 26, 2019 9:13 PM To: m3devel; rodney.m.bates at acm.org Subject: -boot and C backend broken by LLVM? I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot. This is e.g. how you start with AMD64_NT. Well, other than an existing distribution. The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful. I'll try to fix it. I find the builder to be a bit of spaghetti code but maybe I just lack context. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon May 27 09:34:17 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 07:34:17 +0000 Subject: [M3devel] -boot and C backend broken by LLVM? In-Reply-To: References: , Message-ID: Oh, sorry, maybe it works. I can get all the .c files out and compile and link, and crash. Will investigate more.. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, May 26, 2019 9:43 PM To: m3devel; rodney.m.bates at acm.org Subject: Re: [M3devel] -boot and C backend broken by LLVM? I think in particular PushOneM3 got replaced. ? I'll keep looking at it.. ________________________________ From: Jay K Sent: Sunday, May 26, 2019 9:13 PM To: m3devel; rodney.m.bates at acm.org Subject: -boot and C backend broken by LLVM? I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot. This is e.g. how you start with AMD64_NT. Well, other than an existing distribution. The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful. I'll try to fix it. I find the builder to be a bit of spaghetti code but maybe I just lack context. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon May 27 10:11:04 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 08:11:04 +0000 Subject: [M3devel] reducing support for old..? Message-ID: Does anyone mind if: - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP). i.e. use __declspec(thread) (and continue to ignore fibers) i.e. maybe use SRWLOCK and Win32 condition variable. - reduce/remove support for Visual C++ prior to 2015? i.e. assume what we link to wrt msvcrt.lib/libmt.lib i.e. remove the mt.exe support? Config file stuff. - remove support for linking to static C runtime? Config file stuff. I'm torn on all of them. The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write, not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited to active manual development/test with old. On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support. How portable should a portable runtime be? By and large, industry does not support prior to Windows 7. - Related question then as to what to support bootstrapping from. 3.6? 4.0? etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon May 27 11:29:11 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 09:29:11 +0000 Subject: [M3devel] CM3 IR for allocating local jmpbuf? Message-ID: Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.? ? 1.? ? local with the right size and alignment? ? 2.? local pointer initialized with alloca(a particular global)?, that happens to be passed to setjmp? ? ? The second pattern is the more common one these days.? I changed it to that, which is slower, in order? to remove target knowledge from the frontend.? ? I still like that idea.? ? However,? ? 1. Perhaps the optimization of the old way is worthwhile.? Thoughts? Data?? ? 2. I want a third way.? ? I want the C backend to be able to say:? ? #nclude ? ? void function()? {? jmp_buf a;? }? ? with an actual literal "jmp_buf" for the type, to be resolved? via the include of setjmp.h, by the C compiler.? ? Kinda like the old option 1, but the generated C source is actually target-independent.? ? Thoughts on how to best do that?? ? I could pattern match against form 2, but that seems a little gross. Add to M3CG_Options declare_local_jmpbuf?? ? ? Granted, this is a stepping stone.? I really want a higher level try/finally/catch/throw in the IR.? ? The backend should be optionally synthesizing jmpbuf, setjmp, and longjmp? should be up the library, in coordination with the backend? ? ? The C (C++) backend should just be able to say try/catch/throw :)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Mon May 27 11:45:44 2019 From: peter.mckinna at gmail.com (Peter McKinna) Date: Mon, 27 May 2019 19:45:44 +1000 Subject: [M3devel] reducing support for old..? In-Reply-To: References: Message-ID: Go for it. Hasn't the world upgraded to Windows 10? Simply as much as possible but no simpler, (to paraphrase Einstein) Peter On Mon, May 27, 2019 at 6:11 PM Jay K wrote: > Does anyone mind if: > > - reduce/remove support for Windows prior to Vista? (including > Win95/Win98/NT4/Win2000/XP). > i.e. use __declspec(thread) (and continue to ignore fibers) > i.e. maybe use SRWLOCK and Win32 condition variable. > > - reduce/remove support for Visual C++ prior to 2015? > i.e. assume what we link to wrt msvcrt.lib/libmt.lib > i.e. remove the mt.exe support? > Config file stuff. > > - remove support for linking to static C runtime? > Config file stuff. > > I'm torn on all of them. > The old systems weren't that bad to program against, and aren't that > difficult, in some sense to support..well, easy code to write, > not at all easy to test, an ever expanding matrix, unless someone does a > good job of automating it, or is commited > to active manual development/test with old. > > On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that > difficult to support. > > How portable should a portable runtime be? > > By and large, industry does not support prior to Windows 7. > > - Related question then as to what to support bootstrapping from. > 3.6? 4.0? etc. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Mon May 27 11:55:24 2019 From: dmuysers at hotmail.com (dirk muysers) Date: Mon, 27 May 2019 09:55:24 +0000 Subject: [M3devel] reducing support for old..? In-Reply-To: References: Message-ID: People are reluctant to upgrade from Windows 7 to Windows 10, because the new version invades one's privacy. Microsoft thinks that your computer belongs to them, not to you, but --sorry-- enough politics. On 27/05/2019 11:46:44, Peter McKinna wrote: Go for it. Hasn't the world upgraded to Windows 10? Simply as much as possible but no simpler, (to paraphrase Einstein) Peter On Mon, May 27, 2019 at 6:11 PM Jay K > wrote: Does anyone mind if: - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP). i.e. use __declspec(thread) (and continue to ignore fibers) i.e. maybe use SRWLOCK and Win32 condition variable. - reduce/remove support for Visual C++ prior to 2015? i.e. assume what we link to wrt msvcrt.lib/libmt.lib i.e. remove the mt.exe support? Config file stuff. - remove support for linking to static C runtime? Config file stuff. I'm torn on all of them. The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write, not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited to active manual development/test with old. On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support. How portable should a portable runtime be? By and large, industry does not support prior to Windows 7. - Related question then as to what to support bootstrapping from. 3.6? 4.0? etc. - Jay _______________________________________________ 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 May 27 14:06:24 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 12:06:24 +0000 Subject: [M3devel] reducing support for old..? In-Reply-To: References: , Message-ID: But I didn't say Windows 10: - reduce/remove support for Windows prior to Vista? - Jay ________________________________ From: dirk muysers Sent: Monday, May 27, 2019 9:55 AM To: Peter McKinna; Jay K Cc: m3devel at elegosoft.com Subject: Re: [M3devel] reducing support for old..? People are reluctant to upgrade from Windows 7 to Windows 10, because the new version invades one's privacy. Microsoft thinks that your computer belongs to them, not to you, but --sorry-- enough politics. On 27/05/2019 11:46:44, Peter McKinna wrote: Go for it. Hasn't the world upgraded to Windows 10? Simply as much as possible but no simpler, (to paraphrase Einstein) Peter On Mon, May 27, 2019 at 6:11 PM Jay K > wrote: Does anyone mind if: - reduce/remove support for Windows prior to Vista? (including Win95/Win98/NT4/Win2000/XP). i.e. use __declspec(thread) (and continue to ignore fibers) i.e. maybe use SRWLOCK and Win32 condition variable. - reduce/remove support for Visual C++ prior to 2015? i.e. assume what we link to wrt msvcrt.lib/libmt.lib i.e. remove the mt.exe support? Config file stuff. - remove support for linking to static C runtime? Config file stuff. I'm torn on all of them. The old systems weren't that bad to program against, and aren't that difficult, in some sense to support..well, easy code to write, not at all easy to test, an ever expanding matrix, unless someone does a good job of automating it, or is commited to active manual development/test with old. On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that difficult to support. How portable should a portable runtime be? By and large, industry does not support prior to Windows 7. - Related question then as to what to support bootstrapping from. 3.6? 4.0? etc. - Jay _______________________________________________ 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 May 27 14:09:23 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 12:09:23 +0000 Subject: [M3devel] m3 pull requests Message-ID: https://github.com/modula3/cm3/pull/54 https://github.com/modula3/cm3/pull/53 https://github.com/modula3/cm3/pull/52 some O self-approved and commited: https://github.com/modula3/cm3/pull/51 https://github.com/modula3/cm3/pull/50 (maybe should restore whitespace, sorry, though my other git projects cover this up somehow, seemingly, on the server side) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon May 27 14:43:42 2019 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 27 May 2019 08:43:42 -0400 Subject: [M3devel] reducing support for old..? In-Reply-To: References: Message-ID: <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com> On Mon, May 27, 2019 at 07:45:44PM +1000, Peter McKinna wrote: > Go for it. > > Hasn't the world upgraded to Windows 10? > > Simply as much as possible but no simpler, (to paraphrase Einstein) > > Peter There are still a lot of systems still running XP, simply because their software doesn't run on anything later. -- hendrik > > > On Mon, May 27, 2019 at 6:11 PM Jay K wrote: > > > Does anyone mind if: > > > > - reduce/remove support for Windows prior to Vista? (including > > Win95/Win98/NT4/Win2000/XP). > > i.e. use __declspec(thread) (and continue to ignore fibers) > > i.e. maybe use SRWLOCK and Win32 condition variable. > > > > - reduce/remove support for Visual C++ prior to 2015? > > i.e. assume what we link to wrt msvcrt.lib/libmt.lib > > i.e. remove the mt.exe support? > > Config file stuff. > > > > - remove support for linking to static C runtime? > > Config file stuff. > > > > I'm torn on all of them. > > The old systems weren't that bad to program against, and aren't that > > difficult, in some sense to support..well, easy code to write, > > not at all easy to test, an ever expanding matrix, unless someone does a > > good job of automating it, or is commited > > to active manual development/test with old. > > > > On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that > > difficult to support. > > > > How portable should a portable runtime be? > > > > By and large, industry does not support prior to Windows 7. > > > > - Related question then as to what to support bootstrapping from. > > 3.6? 4.0? etc. > > > > - Jay > > _______________________________________________ > > 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 hendrik at topoi.pooq.com Mon May 27 14:46:16 2019 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 27 May 2019 08:46:16 -0400 Subject: [M3devel] CM3 IR for allocating local jmpbuf? In-Reply-To: References: Message-ID: <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com> On Mon, May 27, 2019 at 09:29:11AM +0000, Jay K wrote: > Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.? > ? > 1.? > ? > local with the right size and alignment? > ? > 2.? > local pointer initialized with alloca(a particular global)?, > that happens to be passed to setjmp? > ? > ? > The second pattern is the more common one these days.? > I changed it to that, which is slower, in order? > to remove target knowledge from the frontend.? alloa used to be a nonstandard feature, only available in some C implementations. Has this changed? -- hendrik From jayk123 at hotmail.com Mon May 27 20:18:13 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 18:18:13 +0000 Subject: [M3devel] reducing support for old..? In-Reply-To: <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com> References: , <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com> Message-ID: And we need to provide up to date Modula-3 for them? For how much longer? - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Monday, May 27, 2019 12:43 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] reducing support for old..? On Mon, May 27, 2019 at 07:45:44PM +1000, Peter McKinna wrote: > Go for it. > > Hasn't the world upgraded to Windows 10? > > Simply as much as possible but no simpler, (to paraphrase Einstein) > > Peter There are still a lot of systems still running XP, simply because their software doesn't run on anything later. -- hendrik > > > On Mon, May 27, 2019 at 6:11 PM Jay K wrote: > > > Does anyone mind if: > > > > - reduce/remove support for Windows prior to Vista? (including > > Win95/Win98/NT4/Win2000/XP). > > i.e. use __declspec(thread) (and continue to ignore fibers) > > i.e. maybe use SRWLOCK and Win32 condition variable. > > > > - reduce/remove support for Visual C++ prior to 2015? > > i.e. assume what we link to wrt msvcrt.lib/libmt.lib > > i.e. remove the mt.exe support? > > Config file stuff. > > > > - remove support for linking to static C runtime? > > Config file stuff. > > > > I'm torn on all of them. > > The old systems weren't that bad to program against, and aren't that > > difficult, in some sense to support..well, easy code to write, > > not at all easy to test, an ever expanding matrix, unless someone does a > > good job of automating it, or is commited > > to active manual development/test with old. > > > > On the other hand, NT 3.1, Win95, and Win32s shouldn't be all that > > difficult to support. > > > > How portable should a portable runtime be? > > > > By and large, industry does not support prior to Windows 7. > > > > - Related question then as to what to support bootstrapping from. > > 3.6? 4.0? etc. > > > > - Jay > > _______________________________________________ > > 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 _______________________________________________ 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 May 27 20:23:18 2019 From: jayk123 at hotmail.com (Jay K) Date: Mon, 27 May 2019 18:23:18 +0000 Subject: [M3devel] CM3 IR for allocating local jmpbuf? In-Reply-To: <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com> References: , <20190527124616.z3sdv26vic45nqtu@topoi.pooq.com> Message-ID: It is true that alloca is non-standard, however The use outside of the C backend does not involve C. It is really incredibly portable, even if not standard. We are only using it for a small size. I do propose not using it in the C backend. My interest is more efficiency, but standard conformance would come along as well. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Monday, May 27, 2019 12:46 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 IR for allocating local jmpbuf? On Mon, May 27, 2019 at 09:29:11AM +0000, Jay K wrote: > Hi. The frontend has two ways to communicate to the backend allocation of a local jmp_buf.? > ? > 1.? > ? > local with the right size and alignment? > ? > 2.? > local pointer initialized with alloca(a particular global)?, > that happens to be passed to setjmp? > ? > ? > The second pattern is the more common one these days.? > I changed it to that, which is slower, in order? > to remove target knowledge from the frontend.? alloa used to be a nonstandard feature, only available in some C implementations. Has this changed? -- hendrik _______________________________________________ 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 Tue May 28 00:31:16 2019 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 27 May 2019 18:31:16 -0400 Subject: [M3devel] reducing support for old..? In-Reply-To: References: <20190527124342.ygomsj5ou35tcpyn@topoi.pooq.com> Message-ID: <20190527223115.gv2fcv74hvsikfm5@topoi.pooq.com> On Mon, May 27, 2019 at 06:18:13PM +0000, Jay K wrote: > And we need to provide up to date Modula-3 for them? For how much > longer? > > - Jay I suspect providing a Modula 3 that's as obsolete as XP will work best for them. -- hendrik From dmuysers at hotmail.com Tue May 28 16:31:41 2019 From: dmuysers at hotmail.com (dirk muysers) Date: Tue, 28 May 2019 14:31:41 +0000 Subject: [M3devel] Windows with MS BuildTool Message-ID: Continuing my attempt to compile for X86 on my amd64 host, I removed every remaining trace of past Visual Studio versions by uninstalling everything and removing the corresponding environment variables. I am now left with the MS Visual Studio BuildTool 2019 alone. Trying to compile, I get now: C:\Users\Dirk\Dropbox\projects\libum3\tools\maketables\src>cm3 --- building in ..\NT386 --- -> linking Maketables.exe cl.exe -nologo -DWIN32 -Zl -Z7 -MD -Oi -c _m3main.c -Fo_m3main.obj _m3main.c _m3main.c(1): fatal error C1034: stddef.h: no include path set compile_c => 2 C compiler failed compiling: _m3main.c Fatal Error: cc _m3main.c failed!! The MS compiler being intended primarily for C++ where the some "stddef.h" procedures are implemented as macros, one must include instead include "cstddef.h". I corrected "_m3main.c" manually, but that doesn't work as the quake machinery rebuilds it at every invocation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue May 28 16:56:57 2019 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 28 May 2019 09:56:57 -0500 Subject: [M3devel] -boot and C backend broken by LLVM? In-Reply-To: References: Message-ID: On 05/27/2019 02:34 AM, Jay K wrote: > Oh, sorry, maybe it works. > I can get all the .c files out and compile and link, and crash. Will investigate more.. > > ? - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Jay K > *Sent:* Sunday, May 26, 2019 9:43 PM > *To:* m3devel; rodney.m.bates at acm.org > *Subject:* Re: [M3devel] -boot and C backend broken by LLVM? > I think in particular PushOneM3 got replaced. ? > I'll keep looking at it.. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Jay K > *Sent:* Sunday, May 26, 2019 9:13 PM > *To:* m3devel; rodney.m.bates at acm.org > *Subject:* -boot and C backend broken by LLVM? > I'm pretty sure the merging of the LLVM builder support circa 2015 broke C backend with -boot. > This is e.g. how you start with AMD64_NT. Well, other than an existing distribution. > > The pattern of commenting out large functions, marking them "original" and making new ones nearby is kinda harmful. > > I'll try to fix it. > > I find the builder to be a bit of spaghetti code but maybe I just lack context. Having been into it, I agree it's confusing. But given the fundamental complexity of the task, I'm not sure it could be made less so. > > ?- 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 Wed May 29 03:29:45 2019 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 28 May 2019 20:29:45 -0500 Subject: [M3devel] Finding static areas Message-ID: Anybody know how to get the address ranges of the static constant and static writable areas of the executing linked program? -- Rodney Bates rodney.m.bates at acm.org From dragisha at m3w.org Wed May 29 16:25:20 2019 From: dragisha at m3w.org (Dragisa Duric) Date: Wed, 29 May 2019 16:25:20 +0200 Subject: [M3devel] Finding static areas In-Reply-To: References: Message-ID: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote: > Anybody know how to get the address ranges of the static constant and > static > writable areas of the executing linked program? If I understand this correctly the I think you may find idea on location static writable areas in garbage collector code... Final phases of collection consults global variable spaces. PRobably this will also give a hint for static constant area. From jayk123 at hotmail.com Thu May 30 00:23:38 2019 From: jayk123 at hotmail.com (Jay K) Date: Wed, 29 May 2019 22:23:38 +0000 Subject: [M3devel] Finding static areas In-Reply-To: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> References: , <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> Message-ID: Why? What would you do with such information? On Linux and maybe other systems there are special global variables for this, etext and such. I saw them used in profiling code. But in general there can be multiple such regions, and they can interleave. The Linux variables I think are deprecated. VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase. - Jay ________________________________ From: M3devel on behalf of Dragisa Duric Sent: Wednesday, May 29, 2019 2:25 PM To: rodney.m.bates at acm.org; m3devel Subject: Re: [M3devel] Finding static areas On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote: > Anybody know how to get the address ranges of the static constant and > static > writable areas of the executing linked program? If I understand this correctly the I think you may find idea on location static writable areas in garbage collector code... Final phases of collection consults global variable spaces. PRobably this will also give a hint for static constant area. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu May 30 03:32:47 2019 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 29 May 2019 20:32:47 -0500 Subject: [M3devel] Finding static areas In-Reply-To: References: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> Message-ID: <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop> On 05/29/2019 05:23 PM, Jay K wrote: > Why? What would you do with such information? > I'm writing tests of compiler generation of array constructors. I want to verify where dope is constructed: global area, on stack, etc. > On Linux and maybe other systems there are special global variables for this, etext and such. > I saw them used in profiling code. > But in general there can be multiple such regions, and they can interleave. > The Linux variables I think are deprecated. > > VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase. > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Dragisa Duric > *Sent:* Wednesday, May 29, 2019 2:25 PM > *To:* rodney.m.bates at acm.org; m3devel > *Subject:* Re: [M3devel] Finding static areas > On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote: >> Anybody know how to get the address ranges of the static constant and >> static >> writable areas of the executing linked program? > > If I understand this correctly the I think you may find idea on > location static writable areas in garbage collector code... Final > phases of collection consults global variable spaces. PRobably this > will also give a hint for static constant area. > > _______________________________________________ > 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 May 30 03:46:28 2019 From: jayk123 at hotmail.com (Jay K) Date: Thu, 30 May 2019 01:46:28 +0000 Subject: [M3devel] Finding static areas In-Reply-To: <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop> References: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> , <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop> Message-ID: Windows: GetCurrentThreadStackLimits and range check to see if something is in stack. Windows: VirtualQuery to see if something is readonly or writable. Windows is strict about where the stack is. Because of guard pages and exception handling sanity checking, etc. Unix lets you just malloc and set rsp and everyone pretends exceptions don't exist, so languages cannot interp. So it can be anywhere. For the current code's .data and .rdata, or enumerating each of them, that is pretty easy. Or you could VirtualQuery against some reaodnly and writable globals. I think you'll find it is easy to get this correct though. The "segment" stuff. Modula-3 also goes out of its way to..kinda defeat the linker, and the native debugger. The globals are all smushed together into per-module opaque globals. I guess they are called "segments". So unused data cannot be removed by a nice optimizing linker. And layout is known for garbage collection purposes, w/o a relocation per global. Another design might be to leave each data item "loose", but take the address of GC roots, and collect those into a findable place. And then the take-address will keepalive -- what you really want, and linkers do support this -- is that the address-taken does not keep alive what it refers to, but the other way around. The referred to item has its own linker-decided lifetime, and if it is alive, it will bring in the address-taker or whatever GC data. The Visual C++ compiler/linker have this "associative symbol" feature. The "weak reference" part you would implement by putting the address-taken into a separate .obj. So each global that needs GC data would be "associated with" its GC data. You'd get both or neither. Maybe some day.. But we'd also have to see if ELF and Macho have these features. If you look at the ancient Win32 import lib format from circa 1996, you can see this in action. The null terminals for the various data structures are "associated" with the array elements. Similarly, there are parallel arrays in the data structures. One array is actually referenced, and the other is associated. Sorry this probably doesn't make sense w/o more explanation and is tangential. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, May 30, 2019 1:32 AM To: Jay K; Dragisa Duric; rodney.m.bates at acm.org; m3devel Subject: Re: [M3devel] Finding static areas On 05/29/2019 05:23 PM, Jay K wrote: > Why? What would you do with such information? > I'm writing tests of compiler generation of array constructors. I want to verify where dope is constructed: global area, on stack, etc. > On Linux and maybe other systems there are special global variables for this, etext and such. > I saw them used in profiling code. > But in general there can be multiple such regions, and they can interleave. > The Linux variables I think are deprecated. > > VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase. > > - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Dragisa Duric > *Sent:* Wednesday, May 29, 2019 2:25 PM > *To:* rodney.m.bates at acm.org; m3devel > *Subject:* Re: [M3devel] Finding static areas > On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote: >> Anybody know how to get the address ranges of the static constant and >> static >> writable areas of the executing linked program? > > If I understand this correctly the I think you may find idea on > location static writable areas in garbage collector code... Final > phases of collection consults global variable spaces. PRobably this > will also give a hint for static constant area. > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri May 31 03:20:08 2019 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 30 May 2019 20:20:08 -0500 Subject: [M3devel] Finding static areas In-Reply-To: References: <0a21ea374646541d3a4540f3c7c9d00e1a3b6c37.camel@m3w.org> <78e3d04e-4971-1ce5-422d-57ef5dcdb5e8@lcwb.coop> Message-ID: On 05/29/2019 08:46 PM, Jay K wrote: > Windows:?GetCurrentThreadStackLimits and range check to see if something is in stack. > Windows: VirtualQuery to see if something is readonly or writable. > > Windows is strict about where the stack is. Because of guard pages and exception handling sanity checking, etc. > Unix lets you just malloc and set rsp and everyone pretends exceptions don't exist, so languages cannot interp. > So it can be anywhere. > I am getting stack range quite easily enough by just taking addresses of local variables. > For the current code's .data and .rdata, or enumerating each of them, that is pretty easy. > Or you could VirtualQuery against some reaodnly and writable globals. > > I think you'll find it is easy to get this correct though. > The "segment" stuff. Here's my thinking on segments. Every separate compilation needs the ability to allocate its own stuff in in static readonly (similarly, static read-write areas BTW), which it puts in a segments A traditional linker usually combines all these contiguously, so that hardware memory protection can be applied without major fragmentation. I don't know of any way to control or even know what order the constant segments from the many separate compilations are laid out in. Moreover, I can't take the address of a declared global constant, because a constant is, by language definition, never a designator, even if the compiler were to put it in memory, as is in general almost certain for an array, and certainly what CM3 does. I am thinking there must be some pointers inside the RTS, but it's a lot to comb through, and no luck so far. I was hoping somebody would just happen to know where. > > Modula-3 also goes out of its way to..kinda defeat the linker, and the native debugger. > The globals are all smushed together into per-module opaque globals. I guess they are called "segments". > So unused data cannot be removed by a nice optimizing linker. > And layout is known for garbage collection purposes, w/o a relocation per global. > Another design might be to leave each data item "loose", but take the address of GC roots, and collect those into a findable place. > And then the take-address will keepalive -- what you really want, and linkers do support this -- is that the address-taken does not keep alive what it refers to, but the other way around. > The referred to item has its own linker-decided lifetime, and if it is alive, it will bring in the address-taker or whatever GC data. > > The Visual C++ compiler/linker have this "associative symbol" feature. > The "weak reference" part you would implement by putting the address-taken into a separate .obj. > So each global that needs GC data would be "associated with" its GC data. > You'd get both or neither. > Maybe some day.. > > But we'd also have to see if ELF and Macho have these features. > > If you look at the ancient Win32 import lib format from circa 1996, you can see this in action. > The null terminals for the various data structures are "associated" with the array elements. > Similarly, there are parallel arrays in the data structures. > One array is actually referenced, and the other is associated. > Sorry this probably doesn't make sense w/o more explanation and is tangential. > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Thursday, May 30, 2019 1:32 AM > *To:* Jay K; Dragisa Duric; rodney.m.bates at acm.org; m3devel > *Subject:* Re: [M3devel] Finding static areas > > > On 05/29/2019 05:23 PM, Jay K wrote: >> Why? What would you do with such information? >> > > I'm writing tests of compiler generation of array constructors.? I > want to verify where dope is constructed: global area, on stack, > etc. > >> On Linux and maybe other systems there are special global variables for this, etext and such. >> I saw them used in profiling code. >> But in general there can be multiple such regions, and they can interleave. >> The Linux variables I think are deprecated. >> >> VirtualQuery on Windows is kinda helpful, but more efficiently you can just parse your own PE headers, starting with the linker special symbol __ImageBase. >> >>? ?- Jay >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Dragisa Duric >> *Sent:* Wednesday, May 29, 2019 2:25 PM >> *To:* rodney.m.bates at acm.org; m3devel >> *Subject:* Re: [M3devel] Finding static areas >> On Tue, 2019-05-28 at 20:29 -0500, Rodney M. Bates wrote: >>> Anybody know how to get the address ranges of the static constant and >>> static >>> writable areas of the executing linked program? >> >> If I understand this correctly the I think you may find idea on >> location static writable areas in garbage collector code... Final >> phases of collection consults global variable spaces. PRobably this >> will also give a hint for static constant area. >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > -- > Rodney Bates > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Fri May 31 11:56:57 2019 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 May 2019 09:56:57 +0000 Subject: [M3devel] cm3 -D order vs. config file? Message-ID: % % Unfortunately, command line defines are not currently? % available to the toplevel cm3.cfg.? %? ? ? This seems really broken to me.? At least from a Windows point of view.? ? So you can't say easy things like:? ? cm3 -DTARGET=AMD64_NT -DROOT=c:/s/cm3? ? Instead you have to, environment instead:? ? set CM3_TARGET=x? set CM3_ROOT=y? cm3? ? or Unix not as bad, somewhat more isomorphic: ? CM3_TARGET=x CM3_ROOT=y cm3? Ok if I try to fix it? I thought I had. Maybe I was using an old build to bootstrap.. ? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Fri May 31 12:55:35 2019 From: vvm at tut.by (vvm at tut.by) Date: Fri, 31 May 2019 13:55:35 +0300 Subject: [M3devel] cm3 -D order vs. config file? In-Reply-To: References: Message-ID: <1018801559300135@myt5-02b80404fd9e.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri May 31 19:31:44 2019 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 May 2019 17:31:44 +0000 Subject: [M3devel] calltech parser memory? Message-ID: +++ c:\cm3\bin\cm3.exe -build -DROOT=C:/s/cm3 +++ --- building in NT386 ---? ? ignoring ..\src\m3overrides? ? C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? ? ***? *** runtime error:? *** NEW() was unable to allocate more memory.? *** file "..\src\runtime\common\RuntimeError.m3", line 63? ***? ? ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0x5af93c 0xf24f13 DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? ? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri May 31 19:53:21 2019 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 May 2019 17:53:21 +0000 Subject: [M3devel] calltech parser memory? In-Reply-To: References: Message-ID: Another similar, more of a stack this time: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0xb4f1e4 0x1ce355 GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3? 0xb4f210 0x1ce1fe PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3? 0xb4f258 0x1cdd72 Move + 0x293 in ..\src\runtime\common\RTCollector.m3? 0xb4f29c 0x1f8bcc Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2c0 0x1f84cf DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2ec 0x1f8465 WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f31c 0x1cf6cc CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3? 0xb4f354 0x1cf3bd CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3? 0xb4f360 0x1cef1b CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3? 0xb4f370 0x1ce8ef CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Friday, May 31, 2019 5:31 PM To: m3devel Subject: [M3devel] calltech parser memory? +++ c:\cm3\bin\cm3.exe -build -DROOT=C:/s/cm3 +++ --- building in NT386 ---? ? ignoring ..\src\m3overrides? ? C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? ? ***? *** runtime error:? *** NEW() was unable to allocate more memory.? *** file "..\src\runtime\common\RuntimeError.m3", line 63? ***? ? ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0x5af93c 0xf24f13 DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? ? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri May 31 19:53:56 2019 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 May 2019 17:53:56 +0000 Subject: [M3devel] calltech parser memory? In-Reply-To: References: , Message-ID: Actually this doesn't say out of memory, bug maybe bug in GC? @Tony ________________________________ From: Jay K Sent: Friday, May 31, 2019 5:53 PM To: m3devel Subject: Re: calltech parser memory? Another similar, more of a stack this time: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0xb4f1e4 0x1ce355 GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3? 0xb4f210 0x1ce1fe PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3? 0xb4f258 0x1cdd72 Move + 0x293 in ..\src\runtime\common\RTCollector.m3? 0xb4f29c 0x1f8bcc Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2c0 0x1f84cf DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2ec 0x1f8465 WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f31c 0x1cf6cc CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3? 0xb4f354 0x1cf3bd CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3? 0xb4f360 0x1cef1b CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3? 0xb4f370 0x1ce8ef CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Friday, May 31, 2019 5:31 PM To: m3devel Subject: [M3devel] calltech parser memory? +++ c:\cm3\bin\cm3.exe -build -DROOT=C:/s/cm3 +++ --- building in NT386 ---? ? ignoring ..\src\m3overrides? ? C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? ? ***? *** runtime error:? *** NEW() was unable to allocate more memory.? *** file "..\src\runtime\common\RuntimeError.m3", line 63? ***? ? ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0x5af93c 0xf24f13 DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? ? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri May 31 19:56:04 2019 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 May 2019 17:56:04 +0000 Subject: [M3devel] calltech parser memory? In-Reply-To: References: , , Message-ID: Speaking of which, NT386, there is long-known bug. I'll try to fix soon. SuspendThread + GetThreadContext don't actually work reliably, on wow64, w/o checking some flags and sleep/retry. - Jay ________________________________ From: Jay K Sent: Friday, May 31, 2019 5:53 PM To: m3devel; Tony Subject: Re: calltech parser memory? Actually this doesn't say out of memory, bug maybe bug in GC? @Tony ________________________________ From: Jay K Sent: Friday, May 31, 2019 5:53 PM To: m3devel Subject: Re: calltech parser memory? Another similar, more of a stack this time: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3 ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0xb4f1e4 0x1ce355 GrayBetween + 0x47 in ..\src\runtime\common\RTCollector.m3? 0xb4f210 0x1ce1fe PromotePage + 0x261 in ..\src\runtime\common\RTCollector.m3? 0xb4f258 0x1cdd72 Move + 0x293 in ..\src\runtime\common\RTCollector.m3? 0xb4f29c 0x1f8bcc Walk + 0x448 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2c0 0x1f84cf DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f2ec 0x1f8465 WalkRef + 0xf5 in ..\src\runtime\common\RTHeapMap.m3? 0xb4f31c 0x1cf6cc CleanBetween + 0x137 in ..\src\runtime\common\RTCollector.m3? 0xb4f354 0x1cf3bd CopySome + 0x5e in ..\src\runtime\common\RTCollector.m3? 0xb4f360 0x1cef1b CollectSomeInStateOne + 0x11 in ..\src\runtime\common\RTCollector.m3? 0xb4f370 0x1ce8ef CollectSome + 0x78 in ..\src\runtime\common\RTCollector.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Friday, May 31, 2019 5:31 PM To: m3devel Subject: [M3devel] calltech parser memory? +++ c:\cm3\bin\cm3.exe -build -DROOT=C:/s/cm3 +++ --- building in NT386 ---? ? ignoring ..\src\m3overrides? ? C:/s/cm3\caltech-parser\parserlib\klex\NT386\klex ..\src\Calc.l -o CalcLex.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? ? ***? *** runtime error:? *** NEW() was unable to allocate more memory.? *** file "..\src\runtime\common\RuntimeError.m3", line 63? ***? ? ? ? ***? *** runtime error:? *** <*ASSERT*> failed.? *** file "..\src\runtime\common\RTCollector.m3", line 591? ***? ? Stack trace:? FP PC Procedure? --------- --------- -------------------------------? 0x5af93c 0xf24f13 DefaultBackstop + 0xe3 in ..\src\runtime\common\RTException.m3? ......... ......... ... more frames ...? "c:\cm3\pkg\cit_util\src\generics.tmpl", line 37: quake runtime error: exit 2147483647: C:/s/cm3\caltech-parser\parserlib\kyacc\NT386\kyacc ..\src\Calc.y -o CalcParse.i3 -t ..\src\Calc.t -ti3 CalcTok.i3? ? --procedure-- -line- -file---? exec -- ? _exec 37 c:\cm3\pkg\cit_util\src\generics.tmpl? _xCons 37 c:\cm3\pkg\parserlib\src\parser.tmpl? _pCons 97 c:\cm3\pkg\parserlib\src\parser.tmpl? _pConsUn 99 c:\cm3\pkg\parserlib\src\parser.tmpl? parser 101 c:\cm3\pkg\parserlib\src\parser.tmpl? include_dir 6 C:\s\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile? 5 C:\s\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args? ? Fatal Error: package build failed? *** execution of [, ] failed ***? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: