GDCC: An Alternative ACS Compiler [0.15.0]

[Marrub]

Can confirm GDCC has made working with modding 666% easier.

[Nash]

So, more than a year passed. DH-acc grew in capabilities and was eventually used for stuff. But then it also grew into a monstrosity of conflicting design goals and had to be put down. Thus was born GDCC. First post has been updated to reflect the change. And this post is largely a bump to remind people that I am still crazy and still making compilers for ACS bytecode. :P (New features of GDCC are mentioned in the updated first post.)

Is the syntax still significantly different than regular ACC? The only reason I never got into DH-acc was because porting my project was going to be a nightmare. BCC's syntax was more attractive but it's only for Zandronum so I skipped that too.

[DavidPH]

There are plans to write gdcc-acc after the C front is feature-complete. (Mostly waiting on completion of the libc implementation.)

In the meantime, porting from ACS to C may not be too difficult. The biggest immediate porting problem would probably be replacing #import with #include and headers. The printing syntax is different, being based around an __nprintf function that writes to the native print buffer. This is likely to be annoying, but it is at least a direct translation from ACS syntax. Any usage of global arrays would need to have declarations rewritten, but otherwise usage would mostly remain the same. The differences in function declaration are small, and mostly amount to removing the "function" identifier or making it inert with a macro. Most of the statements and local object declarations are the same, except that variables that need fixed-point types will need to be declared as such. The string and floating literals have slightly different meaning in C, but that can be controlled using pragmas.

Long story short: ACS is sort of a pared down C, so they should be reasonably similar. And porting should be reasonably practical if you are sufficiently familiar with both languages.

EDIT: Even shorter answer: GDCC's C is much closer to ACS than DH-acc's DS.

[Nash]

Great, I'll take a look at it at some point and I'll bug you on IRC if I have any difficulties. :P

[DavidPH]

Version 0.6.0 has been released! Download link is in first post. The goal of this version, was to achieve feature-parity with DH-acc. And while there are some omissions, recently completed porting of certain projects (thanks to marrub and TheMisterCat) has convinced me that it has sufficiently met that goal. Not much has changed in the last few days, as you might expect. But I did commit partial math.h and stdfix.h implementations. The former is missing error and gamma functions and the latter is missing arithmetic and strto functions.

I do not have specific plans for 0.7 goals currently. Not for lack of a massive pile in the TODO list, just not yet decided which to do first.

[Nash]

So when will you start working on gdcc-acc? I assume when GDCC 1.0 is done?

Also, please answer this to me like as if I'm a complete noob: Will gdcc-acc be easy or hard to transition to? Again, I will repeat what I said about BCC and why it would have been a no-brainer for me if it wasn't Zandronum exclusive: It was literally ACC with structs (and other impressive stuff). I didn't have to relearn anything. If gdcc-acc will be anything like BCC... then consider me a confirmed user. :D

[DavidPH]

The primary goal of gdcc-acc would be maximum compatibility with acc's ACS. In that sense it would be relatively easy to transition to. The secondary goal, however, would be to have extensions to ease porting to C. So in that that sense, it would probably be similar to what you describe bcc like.

As far as timing, gdcc-acc is one of the 1.0 goals, so it will be before that. Like I said, I'm mostly waiting for the C front to be sufficiently complete. The reason being that I expect to use stuff (technical programming term) from it for gdcc-acc. That said, cc-lib is probably stable enough already. The first step in gdcc-acc will be arriving at a formal specification for ACS. At the least, a formal grammar. If someone has something like that already, it would be greatly appreciated. I have concerns that I do not know all of ACS's dark corners.

[DavidPH]

The gdcc-acc branch has now been merged into master! So you can compile ACS code with GDCC. Which means for the first time, the title of this thread is literally true. Like gdcc-cc, gdcc-acc only outputs IR files and it uses different options, so it is not a drop-in replacement for acc. However, the language compatibility should be high. Known omissions are CreateTranslation and StrCpy. There are also some issues with str expressions not implicitly casting to int resulting in compile errors where acc would accept the code.

Currently the only specific extension over acc is a fixed type that can be enabled with #pragma FIXED_TYPE ON. Fixed-point literals can be made to have fixed type with #pragma FIXED_LITERAL ON. Both can be enabled at once with #pragma FIXED ON. Without those on, the behavior should be the same as in acc. Other extensions are planned (some already implemented by happenstance), but the priority for the ACS front right now is documentation and improving acc compatibility.

Programs compiled with gdcc-acc implicitly depend on libGDCC. Currently, you can generally get away with not linking in libGDCC, but I make no specific promises about that in the future.

Not specific to the ACS front, but I have also added a --sys-source option which specifies a file relative the the system lib/src directory. So instead of /usr/share/gdcc/lib/src/libc/math.c (or the executable path in Windows) you can say --sys-source libc/math.c. This option is available in gdcc-acc, gdcc-as, and gdcc-cc.

[DavidPH]

Added struct declarations to gdcc-acc. Syntax is mostly the same as C:

Code: Select all • Expand view

struct AwesomeType
{
   int a, b, c;
   fixed x, y, z;
   str s; // Always got to have that wrench in the works.
}

AwesomeType someArray[100000]; // Everyone Loves Memory Excess

global AwesomeType 10:superArray[];

function AwesomeType LetsGetFuncy(AwesomeType bestParameter)
{
   ++bestParameter.a;
   return bestParameter;
}


[Nash]

Why do I feel that this was made out of pressure from me... XD XD XD

[oODemonologistOo]

I can't get this to work properly using batch files. Anyone has one that's ready to use?

[Marrub]

I can't get this to work properly using batch files. Anyone has one that's ready to use?

Here's a project-agnostic batch file I made to compile for GDCC-CC.
http://pastebin.com/Rkb9KDhN
Implied directory tree:
src/ - .c files
inc/ - .h files
GDCC/ - GDCC itself
acs/ - linker output
bin/ - intermediate files
bin/libgdcc - libGDCC/libc intermediate files

[Nash]

^ where to put the PK3/WAD content? Also can you make one for GDCC-ACC? pl0x? :D

[Marrub]

^ where to put the PK3/WAD content? Also can you make one for GDCC-ACC? pl0x?

It's supposed to be put into the PK3, like so:

---

Just change the "CC" variable to gdcc-acc.

[oODemonologistOo]

I'm still a bit puzzled as to how to use this tool. I tried using the batch file and I get lots of "unrecognized command" errors on the "gdcc-cc". Can you elaborate on the process a bit more?