Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Solved] [cm3 AMD64_NT] Modula-3 for Windows x64 ( m3devel 2019-January ) #47

Closed
VictorMiasnikov opened this issue Mar 21, 2019 · 37 comments
Closed

[Solved] [cm3 AMD64_NT] Modula-3 for Windows x64 ( m3devel 2019-January ) #47

VictorMiasnikov opened this issue Mar 21, 2019 · 37 comments

Comments

@VictorMiasnikov
Copy link
Contributor

VictorMiasnikov commented Mar 21, 2019 •
edited
Loading

I think that this need a discussion . . .

It's possible duplicate of
https://m3lists.elegosoft.com/pipermail/m3devel/2019-January.txt

Subject: [M3devel] It's time to AMD_64. Modula-3 for Windows x64

Hi!


 It's time to AMD_64


I started from

https://modula3.elegosoft.com/cm3/uploaded-archives/

cm3-min-AMD64_NT-d5.9.0-VC110-20131012.msi
cm3-all-AMD64_NT-d5.9.0-VC110-20131012.zip


I have worked Modula-3 for Windows x64



There some must important patches:


==
--- RTExFrame.m3 cm3-4e08861fd36f23dcfac6e50e157b36eddf3989b7	Fri Jul 01 10:29:12 2016
+++ RTExFrame.m3	Tue Jun 21 11:59:05 2016
@@ -10,17 +10,17 @@
 (*----------------------------------------- compiler generated descriptors --*)
 
 (* This defines the low-level routines and data structures
    used by the exception runtime.
    See also m3middle/src/M3RT, which also describes these structures.
 *)
 
 (* RTExFrame.Alloca_jmpbuf and Target.Alloca_jmpbuf must match. *)
-CONST Alloca_jmpbuf = TRUE;
+CONST Alloca_jmpbuf = FALSE;
 
 TYPE
   ScopeKind = { Except, ExceptElse,
                 Finally, FinallyProc,
                 Raises, RaisesNone,
                 Lock };
 
 TYPE

==



==
--- Target.m3 cm3-4e08861fd36f23dcfac6e50e157b36eddf3989b7	Fri Jul 01 10:29:12 2016
+++ Target.m3	Tue Jun 21 11:59:05 2016
@@ -59,37 +59,37 @@
     System_name := SystemNames[sys];
 
     OS_name := in_OS_name;
 
     (* common values *)
 
     Atomic_lock_free :=
         ARRAY [CGType.Word8..CGType.Addr] OF BOOLEAN { TRUE, .. };
     (* this is overly optimistic... *)
 
     Allow_packed_byte_aligned := FALSE;
     All_floats_legal          := TRUE;
     PCC_bitfield_type_matters := TRUE;
     Structure_size_boundary   := 8;
     Little_endian             := TRUE;
     Setjmp                    := "_setjmp";
 
     (* RTExFrame.Alloca_jmpbuf and Target.Alloca_jmpbuf must match. *)
-    Alloca_jmpbuf             := TRUE;
+    Alloca_jmpbuf             := FALSE;
 
     (* There is no portable stack walker, and therefore few systems have one.
        Having a stack walker theoretically speeds up everything nicely.  If
        you are familiar with NT exception handling, all but x86 have a stack
        walker.  Not having a stack walker means that functions that have
        try/except/finally/raise incur a codegen cost even if there is never a
        raise -- for having the try.  Having a stack walker means "zero cost"
        for exception handling code that does not actually raise an exception.
 
        If there is NOT a stack walker, prologues/epilogues for functions that
        try/except/finally/raise call PushEFrame / PopEFrame, essentially to
        build a walkable parallel stack.
 
        If there is a stack walker, then raise can discover what PushEFrame /
        PopEFrame effectively recorded.
 
        NT/x86 has a highly optimized equivalent of PushEFrame / PopEFrame, not
        currently used by Modula-3. *)

==




==
--- LazyConsole.i3 000	Thu Nov 01 00:26:16 2018
+++ LazyConsole.i3	Thu Jan 17 13:19:20 2019
@@ -5,7 +5,7 @@
 
 IMPORT File, FileWin32, WinDef;
 
-PROCEDURE New (hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T;
+PROCEDURE New (hd: WinDef.INT32; ds: FileWin32.DirectionSet): File.T;
 (* Returns a file that if ever written to or read from will allocate
    a fresh Windows console for the I/O.  *)
 
==




==
--- LazyConsole.m3 000	Thu Nov 01 00:26:16 2018
+++ LazyConsole.m3	Thu Jan 17 13:20:54 2019
@@ -7,7 +7,7 @@
 
 TYPE
   T = Terminal.T OBJECT
-    hd    : WinDef.DWORD;
+    hd    : WinDef.INT32;
     setup : BOOLEAN := FALSE;
   OVERRIDES
     read   := Read;
@@ -16,7 +16,7 @@
     status := Status;
   END;
 
-PROCEDURE New (hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
+PROCEDURE New (hd: WinDef.INT32; ds: FileWin32.DirectionSet): File.T =
   BEGIN
     RETURN NEW (T, ds := ds, hd := hd);
   END New;
==



==
--- m3makefile 000	Thu Nov 01 00:26:16 2018
+++ m3makefile	Thu Jan 17 14:09:22 2019
@@ -15,7 +15,7 @@
     cp_if(Name & ".i3.tmp", Name & ".i3")
 end
 
-if equal(TARGET, "NT386")
+if equal(TARGET, "AMD64_NT")
   MakeGrisuDisable("GrisuDisable", "TRUE")
 else
   MakeGrisuDisable("GrisuDisable", "FALSE")
==





Best regards, Victor Miasnikov


P.S.

 
 For best working with debugger:


--- RTOS.m3 000	Sun Jan 03 11:17:00 2016
+++ RTOS.m3	Fri Jan 04 13:15:50 2019
@@ -23,10 +23,12 @@
     IF WinBase.IsDebuggerPresent () # 0 THEN
       WinBase.DebugBreak ();
     END;
-    RTThread.SuspendOthers ();
-    RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);
+ (*    RTThread.SuspendOthers ();
+    RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); *)
+    (** RTThread.ResumeOthers ();
     RTSignal.RestoreHandlers (); (* so we really do crash... *)
-    Exit (-1);
+  ***)
+    Exit (4000);  (*** 0 not -1   ***)
   END Crash;
 
 (*********************
 



 Some trivial patches to .cmd:



--- cm3CommandShell.CMD-000     Sun Jan 03 11:17:00 2016
+++ cm3CommandShell.CMD Wed Jan 02 15:24:30 2019
@@ -96,2 +96,3 @@
 echo %_cm3_ThisOS_Long% | (find /I "Windows 7"           >NUL:) && ((set _cm3_ThisOS=Win7)  & goto ver_7)
+echo %_cm3_ThisOS_Long% | (find /I "Windows 10"           >NUL:) && ((set _cm3_ThisOS=Win7)  & goto ver_7)
 echo %_cm3_ThisOS_Long% | (find /I "Windows Server 2008" >NUL:) && ((set _cm3_ThisOS=2008)  & goto ver_2008)
[/code]



--- do-cm3.cmd 000      Sun Jan 03 11:17:00 2016
+++ do-cm3.cmd  Sat Dec 29 11:46:06 2018
@@ -85,6 +85,7 @@
 if NOT exist %SystemRoot%\system32\systeminfo.exe goto ver_NoSysInfo
 FOR /F "usebackq tokens=3* delims=: " %%i IN (`systeminfo ^| find /I "OS Name"`) DO set _cm3_ThisOS_Long=%%i %%j
 echo %_cm3_ThisOS_Long% | (find /I "Windows Vista"       >NUL:) && ((set _cm3_ThisOS=Vista) & goto ver_Vista)
+echo %_cm3_ThisOS_Long% | (find /I "Windows 10"           >NUL:) && ((set _cm3_ThisOS=Win7)  & goto ver_7)
 echo %_cm3_ThisOS_Long% | (find /I "Windows 7"           >NUL:) && ((set _cm3_ThisOS=Win7)  & goto ver_7)
 echo %_cm3_ThisOS_Long% | (find /I "Windows Server 2008" >NUL:) && ((set _cm3_ThisOS=2008)  & goto ver_2008)




--- RCC_upgradeCM3.cmd 000	Sun Jan 03 11:17:00 2016
+++ RCC_upgradeCM3.cmd	Wed Jan 02 16:45:50 2019
@@ -48,7 +48,7 @@
 set _cm3_Repeat=1
 set _cm3_DO=
 set _z_ctrlArgs=
-set _z_Stage3=min
+set _z_Stage3=all
 
 
 
@@ -113,7 +113,7 @@
 if exist "bin\cm3.exe" if exist "pkg" set CM3_ROOT=%CD%& popd & goto FoundRoot
 cd ..
 if exist "bin\cm3.exe" if exist "pkg" set CM3_ROOT=%CD%& popd & goto FoundRoot
-if exist "C:\cm3\bin\cm3.exe" if exist "C:\cm3\pkg" set CM3_ROOT=C:\cm3& popd & goto FoundRoot
+if exist "D:\cm3\bin\cm3.exe" if exist "D:\cm3\pkg" set CM3_ROOT=D:\cm3& popd & goto FoundRoot
 popd
 rem otherwise, search the existing PATH environment variable to try and find the root of the cm3 installation
 for %%F in (cm3.exe) do set CM3_ROOT=%%~dp$PATH:F..
@@ -138,7 +138,7 @@
 if /I "%_cm3_CommandReady%"=="TRUE" goto FindPkgInfo
 echo Setting up environment variables for CM3 ...
 echo.
-call c:\cm3\bin\cm3CommandShell.CMD SameWindow
+call d:\cm3\bin\cm3CommandShell.CMD SameWindow
 @echo off
 if /I not "%_cm3_CommandReady%"=="TRUE" goto FatalSetupCM3
 
@@ -237,7 +237,7 @@
 echo Creating "%CM3_ROOT%\bin\cm3.cfg" ...
 if exist "%CM3_ROOT%\bin\cm3.cfg" del /f %CM3_ROOT%\bin\cm3.cfg
 REM OLD: echo INSTALL_ROOT = path() ^& "/..">%CM3_ROOT%\bin\cm3.cfg
-REM OLD: echo include(path() ^& "/config/NT386")>>%CM3_ROOT%\bin\cm3.cfg
+REM OLD: echo include(path() ^& "/config/AMD64_NT")>>%CM3_ROOT%\bin\cm3.cfg
 copy /y %_cm3_PkgTree%m3-sys\cminstall\src\config-no-install\cm3.cfg %CM3_ROOT%\bin\cm3.cfg
 if errorlevel 1 echo ERROR:  Problem copying files.� & (set _cm3_ExitCode=5) & goto END
 if not exist "%CM3_ROOT%\bin\cm3.cfg" echo ERROR:  Problem copying files.� & (set _cm3_ExitCode=5) & goto END
@@ -287,12 +287,12 @@
 :FN_FinishStage
 :--------------
 if "%_cm3_CM3Failure%"=="TRUE" echo ...skipping installation of cm3.exe due to errors.�.�.� & goto :EOF
-if not exist "%_cm3_PkgTree%m3-sys\cm3\NT386\cm3.exe" goto StageFailure
+if not exist "%_cm3_PkgTree%m3-sys\cm3\AMD64_NT\cm3.exe" goto StageFailure
 echo ...installing new cm3.exe as "%CM3_ROOT%\bin\cm3.exe" ...
 if exist "%CM3_ROOT%\bin\cm3.exe" del /f "%CM3_ROOT%\bin\cm3.exe"
 if exist "%CM3_ROOT%\bin\cm3.pdb" del /f "%CM3_ROOT%\bin\cm3.pdb"
-copy "%_cm3_PkgTree%m3-sys\cm3\NT386\cm3.exe" "%CM3_ROOT%\bin\cm3.exe"
-if exist "%_cm3_PkgTree%m3-sys\cm3\NT386\cm3.pdb" copy "%_cm3_PkgTree%m3-sys\cm3\NT386\cm3.pdb" "%CM3_ROOT%\bin\cm3.pdb"
+copy "%_cm3_PkgTree%m3-sys\cm3\AMD64_NT\cm3.exe" "%CM3_ROOT%\bin\cm3.exe"
+if exist "%_cm3_PkgTree%m3-sys\cm3\AMD64_NT\cm3.pdb" copy "%_cm3_PkgTree%m3-sys\cm3\AMD64_NT\cm3.pdb" "%CM3_ROOT%\bin\cm3.pdb"
 if not exist "%CM3_ROOT%\bin\cm3.exe" goto StageFailure
 goto :EOF
@RodneyBates
Copy link
Contributor

RodneyBates commented Mar 25, 2019 via email

@VictorMiasnikov
Copy link
Contributor Author

Looks like good work.

Thanks!

In fact, it's result of Modula-3 project source code quality: it's good for reading, optimal amount of ASSERTs is very useful for development, etc.

Are there still unsolved problems?

Yes, I think patches need some refactoring.
For example, m3makefile related this:

==

-if equal(TARGET, "NT386")
+if equal(TARGET, "AMD64_NT")

==

need to rewrite for it would be usefull in both case ( 32/64 bits )

Sorry I can't help, for lack of a windows machine.

  1. I can compile, run and etc ( on stage integration my pathes to Modula-3 codebase)
  2. IMHO, virtualization is answer ;-)
  3. Most of problems aren't "pure Windows" problems.

@RodneyBates
Copy link
Contributor

RodneyBates commented Mar 25, 2019 via email

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Mar 26, 2019 •
edited
Loading

Jay K> I had it working long ago with the C backend. :)

a) + b)
What means "it"?
What means "long ago"?

See list of candidates:

"cm3 2016-06-01 Or cm3-56c60ddf3a0027f5fb837cb0e9bd8e089bcbce47 -Ok!- Old"
"cm3 2016-06-21 Or cm3-37a745d3d6f6002c0d90b1aa4526c470a6d0cd12 -Ok!-"
"cm3 2016-07-01 Or cm3-4e08861fd36f23dcfac6e50e157b36eddf3989b7"
"cm3 2016-08-25 Or cm3-cf01df06afdd962bd40aca2a01a83788384dda23"

" ... cm3-5a874253f5f5a82d6553c7ac46cd881841a45f23"

"cm3 cm3-all-AMD64_NT-d5.10.0-VC110-20170824 AMD_64 Target + cm3-master 2017-08-24"
"cm3 cm3-all-AMD64_NT-d5.10.0-VC110-20181031 AMD_64 Target + cm3-master 2018-10-31"
"cm3 cm3-all-AMD64_NT-d5.9.0-VC110-20131012 Pure"

"cm3 2018-08-25 tree--packedVars + Unicode"
"cm3 2018-10-09 tree--coroutines"

c)
"it working" -- are you shue?

With

Alloca_jmpbuf             := TRUE;

it doesn't work:

==

7FF7E54D0000: process D:\cm3\stage\examples\hello\AMD64_NT\hello.exe has started (pid=21484)
7FFD09050000: loaded C:\Windows\system32\ntdll.dll
7FFD08860000: loaded C:\Windows\System32\kernel32.dll
7FFD05600000: loaded C:\Windows\System32\KernelBase.dll
7FFD09082DE0: thread has started (tid=21876)
7FFCCD7E0000: loaded D:\cm3\bin\m3.dll
7FFD09082DE0: thread has started (tid=4016)
7FFCBA4D0000: loaded D:\cm3\bin\m3core.dll
7FFD09082DE0: thread has started (tid=22856)
PDBSRC: loading symbols for 'D:\cm3\stage\examples\hello\AMD64_NT\hello.exe'...
PDB: using DIA dll "C:\Program Files\Common Files\Microsoft Shared\VC\msdia90.dll"
PDB: DIA interface version 9.0
PDB: using load address 7FF7E54D0000
7FFCBA4F16CC: The instruction at 0x7FFCBA4F16CC referenced memory at 0x1. The memory could not be written -> 0000000000000001 (exc.code c0000005, tid 14408)
PDBSRC: loading symbols for 'D:\cm3\bin\m3core.dll'...
PDB: using load address 7FFCBA4D0000
7FFCBA4F16CE: can not decode
7FFCBA4F16CC: failed to calculate step addresses!

==

h)

We are need ( as temporary solution) code a-la this:

-    hd    : WinDef.DWORD;
+    hd    : WinDef.INT32;

because in:

7d01cc2

didn't implement "right fix":

change GetStdHandle, SetStdHandle, GetFileHandle from taking 
DWORD/UINT32 to INT32. The usual constants used here are negative.

Perhaps the right fix though is to state them as large positive.

y)

What means "nonexistent AMD64_NT"?

#16

jaykrell commented on Apr 4, 2017
. . .
But, for example, compared to NT386, it will provide better codegen (inlining), and compared to nonexistent AMD64_NT, infinitely better.

z) "with the C backend" -- in fact "only with C backend" :-(

@jaykrell
Copy link
Contributor

Agreed, only with C backend.
Why INT32 vs. DWORD? These should be about the same.
They should both be 32bits, and Modula-3 doesn't really have an unsigned type, just a BITS 32 FOR INTEGER that you pass to functions. I'll look.

jmpbuf, hm. It is supposed to generally be true:

    AP := Target.Address.pack; (* 32 or 64, same as Target.Integer.pack *)

    EF1_jmpbuf     := EF1_info + EA_SIZE;  (* : jmp_buf *)
    IF Target.Alloca_jmpbuf THEN
      EF1_SIZE       := EF1_jmpbuf + AP;
    ELSE
      <* ASSERT Target.Jumpbuf_size > 0 *>
      EF1_jmpbuf     := RoundUp (EF1_jmpbuf, 128); (* : jmp_buf *)
      EF1_SIZE       := EF1_jmpbuf + Target.Jumpbuf_size;
    END;

and then we call alloca at runtime, and there is a just a pointer here in the frame.

This is slower, but it is more "portabe" because the compiler and runtime do not need per-target information. It can get the size from the target C compiler, here:

Searching for 'jmpbuf'...
C:\s\cm3\m3-libs\m3core\src\unix\Common\Uconstants.c(70):EXTERN_CONST INTEGER m3_jmpbuf_size = 32;
C:\s\cm3\m3-libs\m3core\src\unix\Common\Uconstants.c(73):EXTERN_CONST INTEGER m3_jmpbuf_size = sizeof(jmp_buf) + 16;
C:\s\cm3\m3-libs\m3core\src\unix\Common\Uconstants.c(76):EXTERN_CONST INTEGER m3_jmpbuf_size = sizeof(jmp_buf);
3 occurrence(s) have been found.

I agree Grisu is a problem that I didn't finish looking into.
The C backend was unable to compile it.
It is a rare feat to write Modula-3 that produces uncompilable C.
That does need more attention agreed.

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented May 26, 2019 •
edited
Loading

That does need more attention agreed.

Ok, thank You!

jaykrell pushed a commit to jaykrell/cm3 that referenced this issue May 26, 2019
Make explicit the size of integers smaller than an integer.
f4a167c 
Because of part of modula3#47 (comment).
@jaykrell jaykrell mentioned this issue May 26, 2019
Closed
@jaykrell
Copy link
Contributor

Interesting:

0:000> k
Child-SP          RetAddr           Call Site
000000bc`d3badfd0 00007ffd`7649c77a ntdll!RtlUnwindEx+0x9971e
*** WARNING: Unable to verify checksum for cm3.exe
000000bc`d3bae6b0 00007ff7`286ed68b VCRUNTIME140!_report_gsfailure+0x26a
000000bc`d3baebf0 00007ff7`28b12ecf cm3!Csetjmp__ulongjmp+0x1b
000000bc`d3baec20 00007ff7`28b12a00 cm3!RTExFrame__InvokeHandler+0x10f
000000bc`d3baec60 00007ff7`28b127ae cm3!RTException__ResumeRaise+0x140
000000bc`d3baecc0 00007ff7`28b1e694 cm3!RTException__Raise+0x12e
000000bc`d3baed20 00007ff7`28a0776d cm3!RTHooks__Raise+0xb4
000000bc`d3baedb0 00007ff7`287b8953 cm3!OSErrorWin32__Raise0+0xcd
000000bc`d3baee10 00007ff7`288fabb1 cm3!FS__Status+0x1b3
000000bc`d3baefe0 00007ff7`289ae9e4 cm3!M3File__IsReadable+0xd1
000000bc`d3baf1c0 00007ff7`289ae234 cm3!MxConfig__TryConfig+0x19

So can you explain your jmpbuf change?
And some of the rest? e.g. int32 vs. dword?

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented May 27, 2019 •
edited
Loading

So can you explain your jmpbuf change?

I found ( by "binary search") build of Modula-3 that has described "strange behavior".
And revert changes.

And some of the rest? e.g. int32 vs. dword?

I found some "hacking".
And replace type of related fields and(or) parameters of procedures.

  • reduce/remove support for Visual C++ prior to 2015?

Please, don't "kill" support of VC110 ( "as minimum").
In fact, need support VS with support Windows 2008 R2.
( I don't remember exactly that version of VS can produce .exe/.dll worked on "NT 6.1" )

@jaykrell
Copy link
Contributor

Ok I see the problem with jmpbuf.
You have to call intrinsic _setjmp with newer compiler, in order to pass the correct second parameter.
include setjmp.h is one fix, slow to compile.

@jaykrell
Copy link
Contributor

NT 6.1 is Windows 7, so at least that is kinda recent.
I hear you that 110 remains interesting, ok.
How about with the C backend though? :)

@VictorMiasnikov
Copy link
Contributor Author

newer compiler

I used "VC110" because I has started from cm3-all-AMD64_NT-d5.9.0-VC110-20131012.zip
If need upgrade then I can use VS that downloaded at 2019-01-18 ( or more modern VS 2019)

NT 6.1 is Windows 7, so at least that is kinda recent.
I hear you that 110 remains interesting, ok.
How about with the C backend though? :)

On "today" .exe and .dll generated by Modula-3 for Win x64 "have sense" on
Windows Server 2008 R2
Windows Server 2016
Windows Server 2019

Way that can implement this goal doesn't principal ;-)

(
Jay, please write any e-mail message on my e-mail address.
This can help with possible problems of Hotmail.com antispam

Has You received my e-mail messages?
for example, about RCC_upgradeCM3.cmd?
)

@jaykrell
Copy link
Contributor

I not sure about the email but in general I do nothing with .cmd files. We should delete them, generally. It is horrible language for any purpose. Use the python scripts instead.

Just because old release uses old compiler does not mean we have to keep supporting old compiler. Then we’d never “progress”.

@jaykrell
Copy link
Contributor

Server 2008R2 is probably Windows 7. The names are confusing.

@jaykrell
Copy link
Contributor

Yeah that GetStdHandle change is wierd, or C or Mod3 integers are wierd.
Maybe #53
helps?

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented May 27, 2019 •
edited
Loading

python scripts

I.e. "mklib.exe problem" fixed?

@VictorMiasnikov
Copy link
Contributor Author

(

"May 2019 Archives" looks very strange:

https://m3lists.elegosoft.com/pipermail/m3devel/2019-May/date.htm

•[M3devel] Impossible to compile to recent Windows versions dirk muysers
•[M3devel] Windows with MS BuildTool dirk muysers
•[M3devel] Modula-3 for Windows x64 vvm at tut.by
•[M3devel] reducing support for old..? dirk muysers
•[M3devel] Windows with MS BuildTool dirk muysers

)

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?

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..

Use modern build:

cm3-all-AMD64_NT-d5.10.0-VC110-20190531                                            |  28 M
cm3-all-AMD64_NT-d5.10.0-VC110-20190531-symbols                                    |  21 M
cm3-all-AMD64_NT-d5.10.0-VC110-20190531.wxs _                                      |1778 K
cm3-min-AMD64_NT-d5.10.0-VC110-20190531                                            |3675 K
cm3-min-AMD64_NT-d5.10.0-VC110-20190531-symbols                                    |2511 K
cm3-min-AMD64_NT-d5.10.0-VC110-20190531.wxs _                                      |207789
compiler_with_previous ( step cm3-min-AMD64_NT-d5.10.0-VC110-20190531 ) _          |8572 K
compiler_with_self ( step cm3-min-AMD64_NT-d5.10.0-VC110-20190531 ) _              |9534 K

How sent it to You?

About cm3.cfg

I should be use this:

--- AMD64_NT 000	Mon May 27 21:39:20 2019
+++ AMD64_NT	Thu May 30 11:01:28 2019
@@ -1,6 +1,7 @@
 readonly TARGET_ENDIAN = "LITTLE"   % { "BIG" OR "LITTLE" }
 readonly TARGET_ARCH = "AMD64"
 readonly WORD_SIZE = "64BITS"       % { "32BITS" or "64BITS" }
+if not defined("Unicode_WIDECHAR") Unicode_WIDECHAR = "TRUE" end
 
 M3_BACKEND_MODE = "C"
 


--- Utils.m3 000	Mon May 27 21:39:20 2019
+++ Utils.m3	Thu May 30 11:33:03 2019
@@ -349,9 +349,9 @@
         WCharr.IsUnicode := TRUE;
         Mx.UnicodeWideChar := TRUE; 
       ELSE (* Hardcoded default of last resort: *) 
-        (* Default case: 16-bit WIDECHAR. *) 
-        WCharr.IsUnicode := FALSE; 
-        Mx.UnicodeWideChar := FALSE; 
+        (* Default case: Unicode WIDECHAR. I.e. -- in any case *) 
+        WCharr.IsUnicode := TRUE;
+        Mx.UnicodeWideChar := TRUE; 
       END; 
     END; 
   END InitWidechar;

@VictorMiasnikov VictorMiasnikov mentioned this issue Jun 2, 2019
Merged
@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Jun 12, 2019 •
edited
Loading

*** runtime error:
*** An enumeration or subrange value was out of range.
*** file "..\src\WIN32\TCP.m3", line 310

There is compiling error:

new source -> compiling TCP.m3
"..\src\WIN32\TCP.m3", line 310: warning: value out of range

(

There is line 310 :

IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN

)

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 *)

2020-02-23:
( 2020-02-26: again actual "FIONBIO = -2147195266" variant)
After this path:

--- m3-libs\m3core\src\win32\WinSock.i3 000	Sun Jun 02 21:24:40 2019
+++ m3-libs\m3core\src\win32\WinSock.i3	Tue Feb 23 09:55:12 2021
@@ -574,7 +574,7 @@
     s: SOCKET; addr: struct_sockaddr_star; namelen: INT32): INT32;
 
 <* EXTERNAL ioctlsocket:PASCAL *>
-PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32;
+PROCEDURE ioctlsocket (s: SOCKET; cmd: UINT32; argp: UNTRACED REF UINT32): INT32;
 
 <* EXTERNAL getpeername:PASCAL *>
 PROCEDURE getpeername (

use this correction

--- WinSock.i3 Var {{ FIONBIO =   -2147195266; }} Non-Ok	Tue Feb 23 16:12:52 2021
+++ ..\WinSock.i3	Tue Feb 23 17:06:46 2021
@@ -80,7 +80,7 @@
 
   (* file i/o controls *)
   FIONREAD =  Or (Or (R, INT), Or (FC, 127)); (* Get # bytes to read *)
-  FIONBIO =   -2147195266;  (* Ok only to 32 bit OS   FIONBIO =   Or (Or (W, INT), Or (FC, 126)); (* Set/clear non-bl.i/o *)   *)
+  FIONBIO =   2147772030;  (* Ok only to 32 bit OS   FIONBIO =   Or (Or (W, INT), Or (FC, 126)); (* Set/clear non-bl.i/o *)   *)
   FIOASYNC =  Or (Or (W, INT), Or (FC, 125)); (* Set/clear async i/o    *)
 
   (* Socket i/o controls *)

P.S.

May be FIONREAD is need correction too?

( ADA source code, as example:


FASYNC : constant := FIOASYNC;  
FIOASYNC : constant := 16#8004667d#;  
FIONBIO : constant := -2147195266;  
FIONREAD : constant := 16#4004667f#;

)

@VictorMiasnikov
Copy link
Contributor Author

Q:
The M3devel Archives August 2019 "Text"

RC>>
RC>> I want to get back into using CM3 on Windows.
RC>> I've spent a lot of time over various intervals and tried various editions of Visual Studio,
RC>> but nothing works for me.
RC>>
RC>> Can someone please give us a known starting point and directions on how to:
RC>> 1. Obtain latest working source and minimum working 64-bit compiler for Windows 10.
RC>> 2. Specs on exactly what version of Visual Studio is required.
RC>> 3. Directions on how to rebuild everything
RC>> when source code is updated so that it still works on Windows 10.
RC>>
RC>> Thanks in advance. Randy Coleburn
RC>>

A:

I ( V.V.M.) created some distributives:
cm3-min-AMD64_NT-d5.10.0-VC110-20190602_Unicode_VVMtutby_Edt.7z
cm3-min-AMD64_NT-d5.10.0-VC141-20190602_Unicode_VVMtutby_Edt.7z

Our friend ( Active Oberon, A2 (Bluebottle) developer and GoLang / C # / Delphi software engineer) Yaroslav Romanchenko helped us publish the necessary files on his website ( sage.com.ua ).

cm3 2019-06-02 Unicode AMD_64 Target ( by MS VS 2012)
cm3 2019-06-02 Unicode AMD_64 Target VS 2012

cm3 2019-06-02 Unicode AMD_64 Target ( by MS VS 2017)
cm3 2019-06-02 Unicode AMD_64 Target VS 2017

(
ToDo: write more detailed info after Randy read this short information
)

@jaykrell jaykrell mentioned this issue Feb 21, 2021
Merged
@jaykrell
Copy link
Contributor

Sorry for the huge delay. I commited a fix for setjmp.
And a fix for stack overflows in functions with try.
I can reproduce the int32/dword problem and fixing.

@jaykrell
Copy link
Contributor

Ok, master is much better now? I and I made a release.
It ended up very much like what you did, but not quite.
Grisu: disable for all win32
jmpbuf: I still use alloca, but made related fixes
cmd file: I don't use them, didn't touch.

Grisu someone should look into more.
I expect I'll be disabling it whenever using C backend.

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 22, 2021 •
edited
Loading

Sorry for the huge delay.

No problem -)

I and I made a release.

File
cm3-min-AMD64_NT-d5.10.0-VC2019-20210221.zip
again doesn't contain mklib.exe

It's non Ok state for beginner M3 users.
( I can resend some critics from forum.oberoncore.ru)

It ended up very much like what you did, but not quite.
Grisu: disable for all win32
jmpbuf: I still use alloca, but made related fixes

Thanks!
I'll start testing.

P.S.

Q:
fix for TCP.m3 problem ( related
FIONBIO = -2147195266;
) wasn't be apply yet?

A:
2020-02-23: See fix in WinSock.i3 message:

-  FIONBIO =   -2147195266;
+  FIONBIO =   2147772030;

P.P.S.

I have some problems with MS VS 2012 ( later version doesn't tested yet).
It looks like, most of "my patches public here" still actual.

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 25, 2021 •
edited
Loading 

Jay K}} Jay K:
Jay K}} It worked a lot, and then a lot of:
Jay K}} 
Jay K}} 
Jay K}} 
Jay K}} ***
Jay K}} *** runtime error:
Jay K}} ***    <*ASSERT*> failed.
Jay K}} ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 798
Jay K}} ***
Jay K}} 
Jay K}} 
Jay K}}  . . .
Jay K}} 
Jay K}} any ideas?
Jay K}} 
Jay K}} This is AMD64_NT.
Jay K}} 
Jay K}} 
Jay K}}  . . .
Jay K}} 
Jay K}} 
Jay K}} Re: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem
Jay K}} Jay K
Jay K}} 
Jay K}} 
Jay K}} Ok it seems like a bug in reporting of assertion failures.
Jay K}} 
Jay K}} The repro is:
Jay K}} 
Jay K}} \python27\python boot1.py PA32_HPUX c
Jay K}} 
Jay K}} or
Jay K}} 
Jay K}} \bin\amd64\windbg /g /G /o \python27\python boot1.py PA32_HPUX c
Jay K}} 
Jay K}} which its an assertion failure in the C backend, I will look into.
Jay K}} 
Jay K}}     IF WinBase.IsDebuggerPresent () # 0 THEN
Jay K}}       WinBase.DebugBreak ();
Jay K}}     END;
Jay K}} 
Jay K}} 3:013> k
Jay K}}  # Child-SP          RetAddr               Call Site
Jay K}}                                            KERNELBASE!DebugBreak
Jay K}} 02 000000bc`984fd2c0 00007ff6`4baa2e9f     cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26]
Jay K}}  . . .
Jay K}} 0e 000000bc`984fd720 00007ff6`4b7050f7     cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094]
Jay K}} 
Jay K}} C backend assertion failure here:
Jay K}} 
Jay K}} 0f 000000bc`984fd750 00007ff6`4b7038d4     cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830]
Jay K}}  . . .
Jay K}} 37 000000bc`984ffb60 00007ff6`4bb12974     cm3!main+0x38 [C:\s\cm3\m3-sys\cm3\AMD64_NT\_m3main.c @ 23]
Jay K}} 38 (Inline Function) --------`--------     cm3!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78]
Jay K}} 
Jay K}} 
Jay K}} which if you go past the breakpoint, which simulates no debugger, it hits the assertion failure
Jay K}} I reported:
Jay K}} 
Jay K}} 3:013> k
Jay K}} 
Jay K}} . 13  Id: a35c.8d38 Suspend: 1 Teb: 000000bc`982c8000 Unfrozen
Jay K}}  # Child-SP          RetAddr               Call Site
Jay K}}                                            KERNELBASE!DebugBreak
Jay K}} 02 000000bc`984fc8f0 00007ff6`4baa2e9f     cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26]
Jay K}}  . . .
Jay K}} 0d 000000bc`984fccb0 00007ff6`4bac003a     cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112]
Jay K}} 
Jay K}} The ThreadWin32 assertion failure.
Jay K}} 
Jay K}} 0e 000000bc`984fcd50 00007ff6`4babbf09     cm3!M_ThreadWin32_L_137_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\ThreadWin32.m3.c @ 4356]
Jay K}}  . . .
Jay K}} 2b 000000bc`984fd750 00007ff6`4b7038d4     cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830]
Jay K}} 
Jay K}} 
Jay K}} The first suspend is here:
Jay K}} 3:013> k
Jay K}}  # Child-SP          RetAddr               Call Site
Jay K}} 00 000000d3`6839d2d8 00007ff6`4bae8e28     cm3!RTThread__SuspendOthers [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 793]
Jay K}}  . . .
Jay K}} 0e 000000d3`6839d770 00007ff6`4b7038d4     cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830]
Jay K}} 
Jay K}} 
Jay K}} and then.."funny"..
Jay K}} 
Jay K}} PROCEDURE Crash () =
Jay K}}   CONST Magic = 1 * ADRSIZE (INTEGER);  (* == offset of "fp" in this frame *)
Jay K}}   VAR fp: ADDRESS := ADR (fp) + Magic;  (* == my frame pointer *)
Jay K}}   BEGIN
Jay K}}     IF WinBase.IsDebuggerPresent () # 0 THEN
Jay K}}       WinBase.DebugBreak ();
Jay K}}     END;
Jay K}}     RTThread.SuspendOthers ();                             <== probably the first suspend
Jay K}}     RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);
Jay K}}     RTSignal.RestoreHandlers (); (* so we really do crash... *)
Jay K}}     Exit (-1);                                             <== it gets here
Jay K}}   END Crash;
Jay K}} 
Jay K}} PROCEDURE Exit (n: INTEGER) =                              <== and then here
Jay K}}   BEGIN
Jay K}}     WinBase.ExitProcess (n);
Jay K}}   END Exit;
Jay K}} 
Jay K}} 
Jay K}} and it is our recent friend, a range fault on the exit code.
Jay K}} 
Jay K}} 0f 000000d3`6839d2a0 00007ff6`4bae8e4a     cm3!RTOS__Exit(
Jay K}} int64 n_L_17 = 0n-1)+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16]
Jay K}} 
Jay K}} 
Jay K}} 3:013> u cm3!RTOS__Exit
Jay K}} cm3!RTOS__Exit [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 18]:
Jay K}}  . . .
Jay K}} 00007ff6`4bae8dc4 8b4c2420        mov     ecx,dword ptr [rsp+20h]
Jay K}} 
Jay K}} 
Jay K}} C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1231):<*EXTERNAL ExitProcess:WINAPI*>
Jay K}} C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1232):PROCEDURE ExitProcess (uExitCode: UINT32);
Jay K}} 
Jay K}} Voila.
Jay K}} 
Jay K}} ExitProcess is declared as taking an unsigned integer but we pass negative.
Jay K}} 
Jay K}} So again I think we are being somehow overzealous regarding integer ranges.
Jay K}} 
Jay K}} I mean, I get, that quality is important and this seems correct, based on
Jay K}} some simple principles, but the result seems very unsatifactory.
Jay K}} 
Jay K}} 
Jay K}} On the 32bit system this is Word.T and you can pass any INTEGER value, there are
Jay K}} no checks I guess, and it works.
Jay K}} 
Jay K}} 
Jay K}} But the extension to a 64bit system adds checks and not all INTEGER values are valid,
Jay K}} not even ones that fit in 32bits like -1.
Jay K}} 
Jay K}} 
Jay K}} Would it make sense to declare a type with the "1.5" range -2^31..2^32?
Jay K}} 
Jay K}} Again, I am tempted to change to plain 64bit INTEGER. But that changes e.g.
Jay K}} the type of taking the address.
Jay K}} Pass any value that fits in a register, with the understanding, perhaps not known,
Jay K}} that the upper 32bits are silently ignored???
Jay K}} 
Jay K}} I realize is an exit upon an assertion failure, so it doesn't really matter,
Jay K}} in this case, but Exit(-1) imho should be portable between Win32 and Win64.
Jay K}} 
Jay K}} I know I could say Exit(16_ffffffff) or have a wrapper that does Word.And(Last(UINT32))
Jay K}} but I don't think these should be needed. -1 should be portable between 32bit and 64bit.
Jay K}} 
Jay K}} Please help me to understand and advise what to do?
Jay K}} 
Jay K}} The nested suspend should probably be relaxed somehow too?
Jay K}} 
Jay K}}  - Jay

As temporary solution, please, implement this patch:

--- m3-libs\m3core\src\runtime\WIN32\RTOS.m3 000	Sun Jan 03 11:17:00 2016
+++ m3-libs\m3core\src\runtime\WIN32\RTOS.m3	Thu Feb 25 12:31:36 2021
@@ -23,10 +23,11 @@
     IF WinBase.IsDebuggerPresent () # 0 THEN
       WinBase.DebugBreak ();
     END;
-    RTThread.SuspendOthers ();
-    RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);
-    RTSignal.RestoreHandlers (); (* so we really do crash... *)
-    Exit (-1);
+    (*** RTThread.SuspendOthers ();                                  ***)
+    (*** RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);       ***)
+    (*** RTThread.ResumeOthers ();                                   ***)
+    (*** RTSignal.RestoreHandlers (); (* so we really do crash... *) ***)
+    Exit (4000);
   END Crash;
 
 (*********************

@mikanystrom
Copy link
Contributor

mikanystrom commented Feb 25, 2021 via email

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 25, 2021 •
edited
Loading

}} Passing -1 to WinBase.ExitProcess doesn't elicit a compiler warning (on the 32-bit machine at least)?

I don't remember exactly: I implement this path

 For best working with debugger:


--- RTOS.m3 000	Sun Jan 03 11:17:00 2016
+++ RTOS.m3	Fri Jan 04 13:15:50 2019

long time ago.

P.S.

I think "compiler warning" was generated.

@mikanystrom
Copy link
Contributor

mikanystrom commented Feb 25, 2021 via email

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 25, 2021 •
edited
Loading 

M.N.}} I would do this as follows:
M.N.}} CONST NegOne = LAST(UINT32); 
M.N.}} ...
M.N.}} Exit(NegOne)
M.N.}}

Why not? See patch:

--- m3-libs\m3core\src\runtime\WIN32\RTOS.m3 000	Sun Jan 03 11:17:00 2016
+++ m3-libs\m3core\src\runtime\WIN32\RTOS.m3	Thu Feb 25 13:45:38 2021
@@ -17,16 +17,18 @@
   END Exit;
 
 PROCEDURE Crash () =
+  CONST CrashErrorCodeEqZeroMinusOne = 16_ffffffff;  (* 16_ffffffff = LAST(UINT32) *)
   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 ();
-    RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);
-    RTSignal.RestoreHandlers (); (* so we really do crash... *)
-    Exit (-1);
+    (*** RTThread.SuspendOthers ();                                  ***)
+    (*** RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp);       ***)
+    (*** RTThread.ResumeOthers ();                                   ***)
+    (*** RTSignal.RestoreHandlers (); (* so we really do crash... *) ***)
+    Exit (CrashErrorCodeEqZeroMinusOne);
   END Crash;
 
 (*********************

@RodneyBates
Copy link
Contributor

RodneyBates commented Feb 25, 2021 via email

VictorMiasnikov referenced this issue Feb 25, 2021
@jaykrell
Win64: Fix some unsigned/signed problems around
aabd114 
GetStdHandle, SetStdHandle, ioctlsocket that cause fatal
runtime conditions.
@jaykrell
Copy link
Contributor

jaykrell commented Feb 25, 2021 via email

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 26, 2021 •
edited
Loading

} Win64: Widen some UINT32 parameters to INTEGER. by jaykrell · Pull Request #93

There are one good news and one bad news:

A) Problems with

m3-libs\m3core\src\runtime\WIN32\RTOS.m3

are fixed

Z)

obliqsrv-std.exe run with error:

*** runtime error:
*** Exception "IPError.FatalError" not in RAISES list
*** file "..\src\common\IPError.m3", line 27

@jaykrell
Copy link
Contributor

jaykrell commented Feb 26, 2021 via email

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 26, 2021 via email •
edited
Loading

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Feb 26, 2021 •
edited
Loading

( see later)

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Mar 9, 2021 •
edited
Loading

This patch, as always , take good results:

--- WinSock.i3 000	Fri Feb 26 09:58:54 2021
+++ WinSock.i3	Fri Feb 26 13:02:09 2021
@@ -82,7 +82,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;  (* Ok only to 32 bit OS   FIONBIO =   Or (Or (W, INT), Or (FC, 126)); (* Set/clear non-bl.i/o *)   *)
   FIOASYNC =  Or (Or (W, INT), Or (FC, 125)); (* Set/clear async i/o    *)
 
   (* Socket i/o controls *)

P.S.

Better variant:

24873d4

diff -r -u cm3-6258a91b6cf41b59960c9d31f744c37ed94fa617\m3-libs\m3core\src\win32\WinSock.i3 cm3-24873d4c2f322f1b112d2c0c51a95a1c48a6fb85\m3-libs\m3core\src\win32\WinSock.i3
--- cm3-6258a91b6cf41b59960c9d31f744c37ed94fa617\m3-libs\m3core\src\win32\WinSock.i3	Sun Mar 07 16:03:34 2021
+++ cm3-24873d4c2f322f1b112d2c0c51a95a1c48a6fb85\m3-libs\m3core\src\win32\WinSock.i3	Sun Mar 07 17:52:32 2021
@@ -76,7 +76,7 @@
 
   FC  = Shift (ORD ('f'), 8);
   SC  = Shift (ORD ('s'), 8);
-  INT = Shift (And (BYTESIZE (INTEGER), IOCPARM_MASK), 16);
+  INT = Shift (And (BYTESIZE (u_long), IOCPARM_MASK), 16);
   R   = IOC_OUT;
   W   = IOC_IN;

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Apr 30, 2021 •
edited
Loading

And see new pull request #398 "RCC_upgradeCM3.cmd and Co fixed. Win 10".

P.S. 2021-05-18: integrated to "master", thanks!

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented May 18, 2021 •
edited
Loading

In case compiling by clang-cl.exe from LLVM 9.0.1
by
python upgrade.py && python do-cm3-all.py realclean skipgcc && python do-cm3-all.py buildship

and run Calculator.exe :


***
*** runtime error:
***    An enumeration or subrange value was out of range.
***    file "../src/winvbt/WinTrestle.m3", line 2115
***


D:\cm3\src\m3-ui\ui\src\winvbt\WinTrestle.m3

PROCEDURE DeliverMousePos (hwnd  : WinDef.HWND;
                           lParam: WinDef.LPARAM;
                           wParam: WinDef.WPARAM) =
  (* LL = VBT.mu *)
  VAR
    screenPos := WinDef.POINT {WinDef.LOWORD (lParam), WinDef.HIWORD (lParam)};
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...
  LPARAM = SSIZE_T;
...

...
  SSIZE_T = Cstdint.intptr_t;
...

...
     intptr_t = INTEGER;
...



D:\cm3\src\m3-libs\m3core\src\win32\WinDef.i3
  POINT = RECORD
    x: INT32;
    y: INT32;
  END;



D:\cm3\src\m3-libs\m3core\src\win32\WinDef.i3
(* Types use for passing & returning polymorphic values *)
TYPE
  WPARAM = SIZE_T;
  LPARAM = SSIZE_T;
  LRESULT = SSIZE_T;



D:\cm3\src\m3-libs\m3core\src\win32\WinDef.i3
PROCEDURE LOWORD(l: INT32): UINT16;
<* INLINE *>
PROCEDURE HIWORD(l: INT32): UINT16;
<* INLINE *>



D:\cm3\src\m3-libs\m3core\src\win32\WinDef.m3
<* INLINE *>
PROCEDURE LOWORD (l: INT32): UINT16 =
  BEGIN
    RETURN Word.And(l, 16_ffff);
  END LOWORD;

<* INLINE *>
PROCEDURE HIWORD (l: INT32): UINT16 =
  BEGIN
    RETURN Word.And(Word.Shift(l, -16), 16_ffff);
  END HIWORD;




D:\cm3\src\m3-libs\m3core\src\win32\WinBaseTypes.i3
TYPE
  SIZE_T = Cstdint.uintptr_t;
  SSIZE_T = Cstdint.intptr_t;



D:\cm3\src\m3-libs\m3core\src\C\Common\Cstdint.i3
INTERFACE Cstdint;

TYPE
     intptr_t = INTEGER;
    uintptr_t = Word.T;

@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Oct 11, 2021 •
edited
Loading

There are some related binary and boot files on
https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.3_8a842be

@VictorMiasnikov VictorMiasnikov mentioned this issue Sep 1, 2022
Open
@VictorMiasnikov
Copy link
Contributor Author

VictorMiasnikov commented Sep 7, 2022 •
edited
Loading

All have been fixed, except sub-issue:

***    An enumeration or subrange value was out of range.
***    file "../src/winvbt/WinTrestle.m3", line 2115

I will create another issue ( after re-testing)

@VictorMiasnikov VictorMiasnikov changed the title Modula-3 for Windows x64 ( m3devel 2019-January ) [Solved] [cm3 AMD64_NT] Modula-3 for Windows x64 ( m3devel 2019-January ) Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jaykrell @mikanystrom @RodneyBates @VictorMiasnikov