Page 4 of 16

Re: GDCC: An Alternative ACS Compiler

PostPosted: Fri Mar 20, 2015 6:35 am
by Marrub
oODemonologistOo wrote: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?

Go to your project's directory.
Make a folder named GDCC, put the GDCC distribution in it, so gdcc-cc.exe, gdcc-as.exe, etc are all in there.
Put the batch file into the project directory.
Make two folders, inc and src, and put your header and source files in each respectively.
Run the batch file.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Thu Jun 11, 2015 9:26 am
by Marrub
I have just ported a source code tokenizer library I made to GDCC for a friend, thought it was worthy of posting here since it would appear to be the first C library to implement GDCC compilation.
https://github.com/marrub--/LoveToken
David definitely did not threaten to stab me if I did not post this here.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Thu Jun 11, 2015 10:34 am
by DavidPH
Glorious portable C code. It is almost enough to bring a tear to one's eyes. But only one, and it must be shared between both eyes.

In possibly more exciting news for those who prefer ACS over C, I have considerably improved gdcc-acc's ACS compatibility with acc's ACS since the last time I posted here. This includes better #define scoping with respect to importing and pre-expanded macros to better emulate the way acc evaluates macros as a constant. (The latter behavior can be suppressed with a macro for those who desire the C behavior of simple token substitution.) Once I implement CreateTranslation and StrCpy, I may make a 0.7 release.

Since I definitely made no such threat, it goes without saying that it will now not be carried out.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Tue Jul 21, 2015 2:11 pm
by oODemonologistOo
I recently tried to use this again, and it seems to build the main file fine. However, when I try to launch the mod in Zandronum it just crashes. So I assume it built something else. I changed the CC variable's gdcc-cc to gdcc-acc as Marrub suggested, but still nothing happens. It does compile without errors though. Can send the files in question through PM.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Tue Jul 21, 2015 5:38 pm
by The Zombie Killer
Zandronum 2.0 or 3.0? The latest version of GDCC outright crashes in Zandronum 2.0 for me, however it works fine if I use a slightly older version

Re: GDCC: An Alternative ACS Compiler

PostPosted: Tue Jul 21, 2015 6:37 pm
by oODemonologistOo
The Zombie Killer wrote:Zandronum 2.0 or 3.0? The latest version of GDCC outright crashes in Zandronum 2.0 for me, however it works fine if I use a slightly older version


I forgot to point out, it's actually 2.0. (Or 2.1.2, the newest one not that it changes much in this topic)

Re: GDCC: An Alternative ACS Compiler

PostPosted: Tue Jul 21, 2015 7:02 pm
by edward850
Zandronum 2, at least, doesn't support GDCC in the slightest, due to the old 1000 script allocation restriction, and can potentially crash from out of bounds memory access. 3 wont run it either if it also still lacks named script support.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Wed Jul 22, 2015 12:50 am
by The Zombie Killer
Zandronum 3.0 runs GDCC absolutely fine, as it does indeed support named scripts. (Although you cannot manually puke named scripts online yet, because pukename hasn't been implemented for netplay).

Re: GDCC: An Alternative ACS Compiler

PostPosted: Mon Jul 27, 2015 6:15 am
by DavidPH
edward850 wrote:Zandronum 2, at least, doesn't support GDCC in the slightest, due to the old 1000 script allocation restriction, and can potentially crash from out of bounds memory access. 3 wont run it either if it also still lacks named script support.

The script number limit is hardly the most problematic restriction. And one which is only encountered if one has that many numbered scripts (or explicitly sets a script with such a number). And named scripts are similarly only used if one explicitly asks for it. There is a problem with the new FILE handling which relies on function pointers, but -D__GDCC__NoFuncPtr=1 while compiling stdio.c will fix that. Other than that, I do not know of any other general problems with running GDCC-compiled code with Zandronum 2.x. And the biggest problem with 1.x was the inability to use __nprintf because of how it handled the print buffer.

Just to make it clear: I intend to support Zandronum 2.x until 3.0 sees an official release, so if there are problems with it, I do want to know about them.

For the curious, Zandronum 2.x crashes with function pointer usage because those instruction numbers are used for other things, which results in stack imbalance, which crashes the engine when executing a return instruction because of ZDoom's awkward handling of the call stack. Unfortunately, I did not think of that while rewriting stdio.c to support __fopen_fn, so I apologize for that.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Tue Aug 18, 2015 12:12 pm
by DavidPH
News! I have reached my feature goals for a 0.7 release, including the ability to make a build of gdcc-acc that should act as a drop-in replacement for acc when given two arguments. The first such build is available here with the normal GDCC builds. If there are no new bugs found, I will be doing a 0.7 release soon.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Wed Sep 09, 2015 6:33 pm
by DavidPH
Development continues, including support for C's setjmp/longjmp, strtofx functions, and gdcc-acc bugfixes. And now I have added gdcc-makelib, which is used to compile target libraries without all the tedious mucking about with the exact list of source files for each. First post's Quick Start Guide has been updated appropriately.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Thu Sep 10, 2015 3:10 am
by Marisa Kirisame
Well colour me surprised... I have never heard of such a thing as 96-bit integers, and I've been using C for over half a decade now.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Thu Sep 10, 2015 8:16 am
by DavidPH
It is not a required size, long long only has a minimum of 64 bits, but it seemed like a natural progression. int as the natural word size (32), long as an extended integer (64), and then long long as a more-extended integer (96) when you really really need more bits. That said, it is entirely permitted by the standard, which requires only minimums on the integer types and defers exact sizes to <stdint.h>. Similarly for the also-uncommon 32-bit byte with CHAR_BIT=32.

Re: GDCC: An Alternative ACS Compiler

PostPosted: Thu Sep 10, 2015 9:02 pm
by Nero
So I'm finally venturing into the world of C++ and I had a thought; I remember seeing this compiler that seemed to imply I could use C as a replacement for ACS, I wonder if that compiler would be of any help to me now?

Like I said, I'm just learning C++, in fact I'm taking an introduction class even though it's not part of my major's requirements, so I'm just a newb wondering:
  1. Am I right thinking GDCC can compile C in such a way that I can use it to replace ACS?
  2. Can GDCC compile C++?
  3. How are tasks like the regular ACS specials accomplished (eg Door_Raise, HUDMessage, etc.)?

Re: GDCC: An Alternative ACS Compiler

PostPosted: Fri Sep 11, 2015 7:04 am
by DavidPH
1. Yes, GDCC's C front is capable of doing anything you can do in ACS, though not always as succinctly. If using C for map scripts, it is important to be aware that to have multiple bytecode files not interfere with each other you will need to take extra steps during compiling or write the code in a special way.
2. Sadly, no. Compiling C++ is something I would very much like to do, and should at least be theoretically possible, but it is not going to happen in the foreseeable future.
3. For line specials and builtin functions (both special instruction and callfunc based), there is extension syntax for declaring bindings. The <ACS_ZDoom.h> header includes such bindings, prefixed with ACS_ to avoid name conflicts. For HudMessage and other printing capabilities specifically, one will generally use the __nprintf function (declared in <stdio.h>) which writes to the native print buffer. Additionally, printf and other writes to either stdout or stderr will act like Log calls when a linefeed is written.
Code: Select allExpand view
// Print(s: "A number: ", d: var, s: "!");
ACS_BeginPrint();
__nprintf("A number: %d!", var);
ACS_EndPrint(); // Or ACS_EndLog for Log().

// HudMessage(s: "A"; HUDMSG_PLAIN, msgid, 0, x, y, 0);
ACS_BeginHudMessage();
__nprintf("A");
ACS_MoreHudMessage();
ACS_OptHudMessage(HUDMSG_PLAIN, msgid, 0, x, y, 0);
ACS_EndHudMessage(); // Extra parameters would be given to this function call.

For somewhat more elaborate usage examples, you can look at DUHeresy.

And because it was apparently omitted from the first post during some rewrite, the official IRC channel (for those of you nerdy enough to use IRC (you know who you are)) is #else#if on irc.esper.net.