Jump to content
Excelsior Forums

jiverson

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About jiverson

  • Rank
    Newbie
  • Birthday 01/01/01
  1. compiler failure XDS Modula-2 Linux 2.51

    Hi Andrei, Sorry for the delay in replying. I managed to recode the procedure and avoid the compiler error. The Linux version is Red Hat 9, and the XDS version is 2.51. The changes related to the handling of some (pointers to) dynamically allocated arrays. I don't recall ever seeing that type of error on Linux before. The code was part of a large project, and it would have been difficult to cut down a test case. Thanks for your response. -Scott
  2. RFP contact

    To: the Excelsior staff In the past I have tried to use the RFP form on the Excelsior web site to request information for a project, but I have never received a response to those inquiries. Can someone at Excelsior please contact me at si AT sitexgraphics.com Thanks, Scott
  3. compiler failure XDS Modula-2 Linux 2.51

    Hi Andrei, Thanks for the reply. I don't see an errinfo.$$$ file in the directory with the compiler (or the directory where the compiler was launched). The directory permissions look fine. I thought errinfo files were only produced by the Windows version. Is there another location where the errinfo file might be created? Thanks, Scott
  4. Hi, After making a couple seemingly innocuous changes to the implementation section of a module, attempting to compile the module with XDS Modula-2 2.51 on Linux fails with the following report: * [*** 0.00 F450] * compilation aborted: ASSERT(FALSE, 55656) Any ideas what might be the cause or how the error can be circumvented? The same code compiles fine on Windows. Thanks, Scott
  5. A followup: on a machine with 4 Gb of RAM and Win XP 64 , the test program (with /largeaddressaware enabled) allocates 3.5 Gb before failing. So it looks like a consistent 400-500 mb is inaccessible for some reason. -Scott
  6. Here's the code I added to the test: i:=0; REPEAT Storage.ALLOCATE(a,1000000); INC(i); IF a<>NIL THEN SWholeIO.WriteInt(i,0); END; UNTIL a=NIL; STextIO.WriteLn; After GlobalAlloc returns NIL from the final attemp to allocate 100mb, Storage.ALLOCATE successfully returns 1 1mb block before failing. -Scott
  7. Changing the HEAPLIMIT doesn't appear to affect the result. The test program allocates memory directly from Windows; it does not use the XDS memory manager. I obtain the same results if I allocate a private Windows heap. Does XDS reserve memory for the memory manager (even if it is not used) or do something else that might limit the available memory? The only other cause that comes to mind is something related to how the executable is linked and/or loaded into memory. The real application that exposed this strange limit is a 3D rendering app that really needs to have access to as much memory as possible. Any help or hint you can provide would be much appreciated. Thanks, Scott
  8. Thanks for the quick response. I modified the test program to fill the allocated memory. The respective max memory allocated is: XDS - 1.4 G Stonybrook - 2.0 G MSC - 1.8 G The Stonybrook test takes noticably longer to complete when filling memory, so I'm reasonably certain that the compiler is not optimizing away the initialization. I can make an executable compiled with Stonybrook available if that would be helpful. Thanks, Scott MODULE test; FROM SYSTEM IMPORT ADDRESS, CAST; IMPORT STextIO, SWholeIO; <*IF Stonybrook THEN*> IMPORT WIN32; <*ELSE*> IMPORT Windows; <*END*> CONST TestSize = 100000000; PROCEDURE Test; VAR i,j : INTEGER; a : POINTER TO ARRAY [0..TestSize] OF CHAR; BEGIN i:=0; REPEAT <*IF Stonybrook THEN*> a:=WIN32.GlobalAlloc(WIN32.GMEM_FIXED,TestSize); <*ELSE*> a:=CAST(ADDRESS,Windows.GlobalAlloc(Windows.GMEM_FIXED,TestSize)); <*END*> INC(i); IF a<>NIL THEN FOR j:=0 TO TestSize-1 DO a^[j]:="A"; END; SWholeIO.WriteInt(i,0); END; UNTIL a=NIL; STextIO.WriteLn; END Test; BEGIN Test; STextIO.WriteString("done"); STextIO.WriteLn; END test.
  9. Hello, Applications compiled with native XDS Modula-2 on Windows seem to limit the maximum memory available to an application to about 1.5 GB. Other compilers allow up to 2 GB. I've attached a small test program below. When compiled with XDS (v 2.45) it exits at around 1.5 GB under Win 2K and Win XP Pro. When compiled with the Stonybrook compiler, the program reachs 2 GB. A similar C program compiled with MSC 6 also allocates up to 2 GB. Any ideas as to the cause? Is there a compiler or linker option that can be used to overcome this limitation? Thanks for any help. -Scott MODULE test; FROM SYSTEM IMPORT ADDRESS; IMPORT STextIO, SWholeIO; <*IF Stonybrook THEN*> IMPORT WIN32; <*ELSE*> IMPORT Windows; <*END*> PROCEDURE Test; VAR i : INTEGER; a : ADDRESS; BEGIN i:=0; REPEAT <*IF Stonybrook THEN*> a:=WIN32.GlobalAlloc(WIN32.GMEM_FIXED,100000000); <*ELSE*> a:=Windows.GlobalAlloc(Windows.GMEM_FIXED,100000000); <*END*> INC(i); SWholeIO.WriteInt(i,0); UNTIL a=NIL; STextIO.WriteLn; END Test; BEGIN Test; STextIO.WriteString("done"); STextIO.WriteLn; END test.
×