drmortalwombat / oscar64

Optimizing Small memory C Compiler Assembler and Runtime for C64
GNU General Public License v3.0
261 stars 21 forks source link

Compiler crashes in PeepHoleOptimizer #54

Closed KungPhoo closed 5 months ago

KungPhoo commented 5 months ago

The stack is: 7 wassert ucrtbased 0x7ffa0c293a1f 8 NativeCodeBasicBlock::CheckLive NativeCodeGenerator.cpp 46051 0x7ff6e62381a1 9 NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 40985 0x7ff6e610cea9 10 NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 45942 0x7ff6e6147f36 11 NativeCodeProcedure::Optimize NativeCodeGenerator.cpp 47565 0x7ff6e623d18c 12 NativeCodeProcedure::Compile NativeCodeGenerator.cpp 46872 0x7ff6e6239228

I'll add my code for this project, too. The command line is: oscar64.exe c64stuff.c gfx.c puzzleboy.c puzzleboy_door.c puzzleboy_draw.c main.c src.zip

drmortalwombat commented 5 months ago

Fix checked in.

Also, please make sure to use "volatile" with your "PEEK" and "POKE" macros to prevent the compiler from caching, reordering or optimizing your memory accesses.

KungPhoo commented 5 months ago

Thank you for the very fast reply. Now, unfortunately, I get a stack overflow. I think too deep recursion. Here's the stack trace:

2  NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 38761 0x7ff66a33a5cb 
3  NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 45950 0x7ff66a38840e 
4  NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 45950 0x7ff66a38840e
...
44 NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 45950 0x7ff66a38840e 
45 NativeCodeBasicBlock::PeepHoleOptimizer NativeCodeGenerator.cpp 45950 0x7ff66a38840e 
46 NativeCodeProcedure::Optimize           NativeCodeGenerator.cpp 47573 0x7ff66a47d65c 
47 NativeCodeProcedure::Compile            NativeCodeGenerator.cpp 46880 0x7ff66a4796f8 
48 Compiler::CompileProcedure              Compiler.cpp            469   0x7ff66a21a0aa 
49 Compiler::CompileProcedure              Compiler.cpp            458   0x7ff66a219fe2 
50 Compiler::CompileProcedure              Compiler.cpp            458   0x7ff66a219fe2 
51 Compiler::GenerateCode                  Compiler.cpp            1018  0x7ff66a21898f 

Even with #define POKE(addr, val) (*(volatile unsigned char *)(addr) = (unsigned char)(val))

The recursion happend here:

        assert(mIndex == 1000 || mNumEntries == mEntryBlocks.Size());

        if (this->mTrueJump && this->mTrueJump->PeepHoleOptimizer(proc, pass)) // <<<<<<<<<<<<<
            changed = true;
        if (this->mFalseJump && this->mFalseJump->PeepHoleOptimizer(proc, pass))
            changed = true;

BTW: I'm switching to Oscar64, because my program seems to be quite big and other compilers overwrote the character set memory with my code. How can I "protect" a piece of memory, so Oscar64 won't put code in it?

Like this?

#pragma region( nocode, 0x3000, 0x3800, , , {charset} )
#pragma data(charset)
volatile char charset[0x800];
drmortalwombat commented 5 months ago

A recursion depth of 50 is not very deep. The standard windows build sets the stack size to 16MB which is sufficient for even large programs. On linux the stack size should depend on the ulimit setting. Can you provide information on your build environment, so I can try to recreate the issue?

If you want to place your resource in low memory (e.g. 0x3000) you have to split the main region to avoid double booking. The samples/memmap/charsetlo.c is an example for this.

KungPhoo commented 5 months ago

So, it doesn't crash for you? Very strange. I used the MSVC 2015 (v14) build tools. I made a CmakesList.txt and used CMake/QtCreator, since I was unable to build the provided sln file with my visual studio version. I'll try with the MinGW GCC. Thank you.

30 Mar 2024 08:59:32 drmortalwombat @.***>:

A recursion depth of 50 is not very deep. The standard windows build sets the stack size to 16MB which is sufficient for even large programs. On linux the stack size should depend on the ulimit setting. Can you provide information on your build environment, so I can try to recreate the issue?

If you want to place your resource in low memory (e.g. 0x3000) you have to split the main region to avoid double booking. The samples/memmap/charsetlo.c is an example for this.

— Reply to this email directly, view it on GitHub[https://github.com/drmortalwombat/oscar64/issues/54#issuecomment-2027959837], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAVWMM3QMHYFMZD7YEDP4FTY2ZPFFAVCNFSM6AAAAABFHXJBCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXHE2TSOBTG4]. You are receiving this because you authored the thread. [Tracking image][https://github.com/notifications/beacon/AAVWMMZNNZWGNQEQ66N3TN3Y2ZPFFA5CNFSM6AAAAABFHXJBCKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTY4A3B2.gif]

drmortalwombat commented 5 months ago

This explains your problem. The default stack size of visual studio is to small. You can set the stacksize with the linker command line option: /STACK:"16000000"

KungPhoo commented 5 months ago

It works. Thank you so much.