GDCC: An Alternative ACS Compiler [0.15.0]

[The Zombie Killer]

Just use a simple batch file to build your C code (if on Windows. A shell script for Linux would be just as simple), this is what I generally use (I have a folder containing GDCC in my PATH variable):
EDIT: Tidied it up

Code: Select all • Expand view

@echo off
if not exist acs mkdir acs
if not exist ir mkdir ir

if not exist acs\libc.bin (
   echo Building libc . . .
   gdcc-makelib --bc-target=ZDoom --bc-zdacs-init-delay --alloc-min Sta "" 1000000000 libGDCC libc -o acs/libc.bin
)

echo Building game lib . . .
gdcc-cc --bc-target=ZDoom -c source/*.c ir/game.ir
gdcc-ld --bc-target=ZDoom --bc-zdacs-init-delay -llibc ir/game.ir acs/game.bin

echo Press any key to exit . . .
pause >> nul

[Sarah]

@Nash: You're template still works fine with some modification to fit the latest GDCC builds, I just needed a bit of help getting it there. When I get it all sorted out, I'll share the changes with you if you want to update the template post; maybe split it into an ACS template and a C template?

@TZK: That batch works with just a few tweaks, most of which need reverted to make it generic enough for a template; I don't generally edit my PATH variable so giving the batch a direct route to GDCC is imperative.

Two questions remain:
1 - Why two files now? I assume the libc file is the standard C stuff I use and the other is my own source, but can we combine them together like in the past for just one library?
2 - (I think this is an optimization question) Older builds of my source required an edit to the ACS-VM at the source level to increase the instruction count so the code wasn't considered an infinite loop. That worked fine until today when the compiled code suddenly started getting killed by the VM again. So my question is, what is the following line from the batch instructing GDCC to do, and especially what are those parameters and could they be related to my sudden instruction count issue?

Code: Select all • Expand view

gdcc-ld --bc-target=ZDoom --bc-zdacs-init-delay --alloc-min Sta "" 1000000000 ir/libc.ir ir/libGDCC.ir acs/libc.bin

edit: @TZK a thank you is also in order, so thank you my good fellow!

[Marrub]

1 - libc is libc. If you've never used a C compiler, it's the standard library, which is exposed via the standard headers; ie stdlib.h, stdio.h, etc.
You don't want to compile it every time because it takes ages and is around 900kb of intermediate code, so the batch script compiles it only once.
Be wary, though, that if you update GDCC, you will need to delete and recompile the libc IR file.

2 - They're definitely not related. It's more likely that you were using a pre-setjump/longjmp version of GDCC, wherein less instructions occurred at the start of a function.
You can look up what those arguments do via GDCC's wonderful command-line help command, gdcc-ld --help. Those in particular are for making sure it doesn't explode if another GDCC script (such as from a map) is loaded along with yours.

[DavidPH]

The long jump stuff is pretty old, though, and the call post is not so bad. (I think I have used the term "prologue" in the past because I am bad at English.) I would be quicker to implicate the stdio rewrite. While it should be efficient for what it is, it may not be as fast as some of the older implementations for certain uses. In particular, the sprintf family of functions is likely not as efficient now that it goes through vfprintf rather than being its own printing implementation. (But no longer makes me vomit blood and death and 「くそコド」 whenever I look at it.) But if you were indeed using a build from before the long jump capability, that would add a little extra load. Some day I will get to work on adding ways to reduce the number of long jump checks generated. Both compiler options and attributes. (Maybe some pragmas.)

As for doing a separate libc binary, as Marrub said, the advantage is a much easier time with having multiple GDCC-based libraries active at once. The disadvantage is mostly just the inconvenience of needing all the extra options to gdcc-ld. On a side note, you could compress the three commands into:

Code: Select all • Expand view

gdcc-makelib --bc-target=ZDoom --bc-zdacs-init-delay --alloc-min Sta "" 1000000000 libGDCC libc -o acs/libc.bin

Also, I want to give a big thanks to both Marrub and TheZombieKiller for being willing to tinker with build scripts for people to use. User interface design is definitely not my thing, so I appreciate their continued patience and dedication.

[yqco]

I've noticed that gdcc-cc silently allows variables and functions to be redefined, even with --warn-all or --warn-redefinitions on. For example, the following snippet compiles just fine:

Code: Select all • Expand view

int foo(int bar) {
    int bar = 0; // gcc error: redefinition of 'bar'
    return bar;
} 

Likewise:

Code: Select all • Expand view

int baz(void) {
    return 0;
}

int baz(void) { // gcc error: redefinition of 'foo'
    return 0x7FFFFFFF;
} 

Calling baz() appears to use the last definition. The tests were compiled with the latest Windows 64-bit release (gdcc_v0.10.0-10-g83f122c_win64) using:

Code: Select all • Expand view

gdcc-makelib --bc-target=ZDoom --bc-zdacs-init-delay --alloc-min Sta "" 1000000000 libGDCC libc -oacs/libc.bin
gdcc-cc --warn-all --warn-redefinition --bc-target=ZDoom -llibc -oacs/test.bin test.c

Obviously this can lead to difficult to find bugs. Would it be feasible to add support to gdcc-cc to catch these type of errors?

Also I don't seem to understand how gdcc-ar-wad works. I'm trying to list the contents of a WAD but the output file only contains the WAD name. I've tried a few different WADs but always get the same results:

Code: Select all • Expand view

gdcc-ar-wad --list=lumplist.txt D:\<path_to_wads>\doom.wad

Where lumplist.txt contains:

Code: Select all • Expand view

doom



[DavidPH]

That first code example is a legal shadowing case, and shadowing warnings are notoriously difficult to get right, so they are a low priority for now. The latter should actually be an error already, but I must have missed something. Will try to fix as soon as I can.

As for gdcc-ar-wad, to load a wad file you need to prefix the filename with wad:. Otherwise it is taken as just a file to add. Proper documentation for gdcc-ar-wad is also on the TODO list, but a low priority given the relatively niche use cases. (I mostly wrote it to replace DH-wad in my test scripts.)

In other news that may be of interest to people, the old restriction on StkCall functions (and by extension LangACS functions) of not being able to use automatic storage has been lifted. Automatic storage will be allocated if needed, and can be configured with the [[alloc_Aut]] attribute. This should make writing ACS APIs for C libraries require much less boilerplate.

[yqco]

Sorry, I wasn't aware of the difficulty of my request. Knowing this, I'd say don't worry about it as the gain probably isn't worth the effort.

Are you sure the first example is legal though? The variables share the same scope: https://glot.io/snippets/ehcvchrspd

---

this program compiles fine with gdcc-cc:

Code: Select all • Expand view

#include <ACS_ZDoom.h>
#include <stdio.h>

[[call("ScriptS"), script("Open")]]
void redefinition(void)
{
    int a = 0;
    ++a;
    ACS_BeginLog(); __nprintf("First: %d", a); ACS_EndLog();

    int a = 10;
    ++a;
    ACS_BeginLog(); __nprintf("Second: %d", a); ACS_EndLog();

    int a = 100;
    ++a;
    ACS_BeginLog(); __nprintf("Third: %d", a); ACS_EndLog();
} 

Where the output is:

Code: Select all • Expand view

First: 1
Second: 11
Third: 101

The output from gdcc-ar-wad is working as expected now. Thank you!

[Nash]

Does gdcc-acc support KILL scripts yet?

[DavidPH]

I was under the impression that parameters had a different scope than the function's main block. But being able to declare the same name multiple times in the same block definitely should be an error, so I will see what I can do.

Does gdcc-acc support KILL scripts yet?

It does now.

[Nash]

Aaaand it's me, back to pester you more. >8D

Can you add REOPEN script support? Thanks <3

[DavidPH]

Done.

[Nash]

I tried making a REOPEN script with gdcc_v0.11.0-7-g2b09735_win64.7z but it doesn't seem to work...

ERROR: zmain.acs:187:30: expected '{' got 'reopen'
Errors found in compiling ACS libraries. Aborting...

[DavidPH]

Forgot that I have to add it to ACC separately. Done for real, now.

[Nash]

Thanks! Sorry to bother you again D: but it looks like only the source package is uploaded into the your /builds Dropbox... no x86/x64 binaries... :S

(unless it's under some automated system and I just have to wait?)

[DavidPH]

There was apparently some kind of error in my upload script, but the builds are up now.