Can't compile Albion for LLasm

[IS4Code]

I am getting an error when compiling Albion for the LLVM target:

./SR.exe ALBION.EXE out

Output type: LLasm version
esp dword aligned: no
ebp dword aligned: no
2022-12-20 02:33:17.555: Loading EXE file...
        Sections in file: 8
2022-12-20 02:33:17.563: Loading source code information...
2022-12-20 02:33:17.563: Initial disassembly...
2022-12-20 02:33:17.857: Applying fixup...
2022-12-20 02:33:17.909: Full disassembly...
Error: unknown flags on start of region - 0 - 32084 (0x17d54) - 0x38
Error: 

The x86 target is compiled successfully. I am using CentOS 8.

[M-HT]

Albion doesn't support the llasm target at the moment. It supports x86 and arm targets.

[IS4Code]

Is it possible to make it working with llasm, please?

[M-HT]

What would you use it for ?

[IS4Code]

I am thinking about making Albion run in the browser, by compiling the LLVM IR to WebAssembly, if that is possible...

[M-HT]

I don't know if that's possible or not. Maybe you can first try to compile something which already supports llasm target - the intro executable from X-Com: UFO Defense (UFO: Enemy Unknown) or Septerra Core: Legacy of the Creator.

[IS4Code]

Well, at the moment I don't have much luck compiling UFO: Enemy Unknown either:

./SR.exe INTRO.EXE intro-asm.llasm
Output type: LLasm version
esp dword aligned: yes
ebp dword aligned: yes
2022-12-20 13:24:11.729: Loading EXE file...
        Sections in file: 3
2022-12-20 13:24:11.730: Loading source code information...
        Loading fixup_interpret_as_code.sci...
        Loading external_procedures.sci...
        Loading global_aliases.sci...
        Loading instruction_replacements.sci...
2022-12-20 13:24:11.730: Initial disassembly...
2022-12-20 13:24:11.744: Applying fixup...
2022-12-20 13:24:11.747: Full disassembly...
Error: output not found - 0 - 0x7fa
Error: 1

MD5 of INTRO.EXE: ad8322dec6c8f09a2ffebd8d4977d779

[M-HT]

That's probably because you have a different INTRO.exe.

Required INTRO.EXE is from the DOS English version 1.4.

• file size: 74314 bytes
• md5: 28098b9411d9454ad6676d99cefc0e4b
• sha1: 927f0896dc91eea3b948ad60ed71870843ce5ad0
• sha256: 513569ceea82ee0b265cad3605b82324ac1adcd98adbff7f6ce0fbef7af4da30

[IS4Code]

Thanks, I had to find a patch to 1.4, but now I can't find gdc to compile llasm. Could you please upload a binary of it somewhere?

[M-HT]

Try this one: llasm.tar.gz

[xcom169]

Hello All!

Did you try Nasm 2.16 ? Is it working well with SR?

[M-HT]

Nasm 2.16 works with SR. The bug present in versions 2.15.03 -- 2.15.05 was fixed.

[IS4Code]

Try this one: llasm.tar.gz

Thank you! I managed to compile it, and now I am trying to get SDL2 work in emscripten. So far it seems like SDL_CreateSemaphore is not working... I'll update when I get it to work.

I also found an error possibly unrelated to WASM:

Uncaught RuntimeError: null function or function signature mismatch
    at MidiPlugin_Shutdown (Intro-music-midiplugin.c:584:5)
    at Game_Cleanup (main.c:875:21)
    at Game_Initialize (main.c:1165:9)
    at main (main.c:1919:24)

Perhaps MP_functions.shutdown_plugin does not exist yet at this point in Game_Initialize?

[IS4Code]

Well I got it to a point where it runs a few events and then quits. Not sure where to go from there...

[M-HT]

Either find a way to debug it or add printf statements to the code to see where it stops executing.

As for the error - it occurs when the game fails to initialize. I'll fix it, but it's not what prevents the game from running.

[IS4Code]

Seems to be exitting from X86_InPortProcedure:

out 0x43
size 1
eax 0x63736d65
al 0x65

I have suppressed that situation with return; but now recursion is the problem:

RangeError: Maximum call stack size exceeded
    at X86_OutPortProcedure (Intro-inout.c:66:1)
    at x86_out_imm_al (llasm_inout.c:82:46)
    at .Lloc_110B0 (llasm_stos.c:43:1)
    at .Lloc_11091 (llasm_stos.c:43:1)
    at .Lloc_110B0 (llasm_stos.c:43:1)
    at .Lloc_11091 (llasm_stos.c:43:1)
    at .Lloc_110B0 (llasm_stos.c:43:1)
    at .Lloc_11091 (llasm_stos.c:43:1)
    at .Lloc_110B0 (llasm_stos.c:43:1)
    at .Lloc_11091 (llasm_stos.c:43:1)

I suppose this is a good time to mention that I had to remove musttail from the generated LLVM code, since WebAssembly does not support tail-calls yet. I had hoped performance would be all that would affect, but if the code cannot run properly without it, we may need to wait a few years before tail-calls become supported.

[M-HT]

When a target doesn't support tails-calls, then use llasm with parameter -no-tail-calls, which generates slower code without tails-calls. You can't just remove musttail without doing anything else, otherwise you get infinite recursion.

X86_InPortProcedure doesn't have such debug text - that's debug text from X86_OutPortProcedure.

[IS4Code]

Thanks! Yeah I meant X86_OutPortProcedure, but copied the wrong name.

-no-tail-calls has fixed the recursion, and now it even seems to be launching somewhat, I can see it open the UFOINT.FLI file (and it sets the SDL window size), but nothing is drawn to the screen and it quits after a short while, with this

Simulating Real Mode Interrupt: 66h
Running Original Interrupt...
Running function: eax=0x101
DIGPAK: stopping sound
Exit code: 7799984

One thing I also had to guess was which of the .c files in the audio, input, and display folders to use for the WebAssembly target. I went with pc, but perhaps something specialized is needed...