GDCC: An Alternative ACS Compiler [0.15.0]

Any utility that assists in the creation of mods, assets, etc, go here. For example: Ultimate Doom Builder 2, Slade, WadSmoosh, etc.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
Blox
Posts: 3728
Joined: Wed Sep 22, 2010 9:35 am
Location: Apathetic Limbo

Re: [WIP] DH-acc: ACS C Compiler

Post by Blox »

Crazy stuff, but why am I posting here when I can't use this anyway. :p
Gez wrote:We've got to go deeper.
Engineception. :lol:
User avatar
printz
Posts: 2646
Joined: Thu Oct 26, 2006 12:08 pm
Github ID: ioan-chera
Operating System: Windows 10/8.1/8/201x 64-bit
Location: Bucharest, Romania

Re: [WIP] DH-acc: ACS C Compiler

Post by printz »

I'm gonna be a bit cynical and ask what projects so far are demanding a more flexible BEHAVIOR compiler, like this one...
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [WIP] DH-acc: ACS C Compiler

Post by Blzut3 »

printz wrote:I'm gonna be a bit cynical and ask what projects so far are demanding a more flexible BEHAVIOR compiler, like this one...
Like this one? Can't really answer that, however I can say that my ACS compiler was started because ACS heavy projects (specifically Blackfire) could really use new compile time constructs to simply their code. Language features can make all the difference between maintainable and unmaintainable code.
CommanderZ wrote:Wow, I was thinking of doing exactly this myself, so thumbs up!
Heh, how many people are writing ACS compilers now?
Gez
 
 
Posts: 17635
Joined: Fri Jul 06, 2007 3:22 pm

Re: [WIP] DH-acc: ACS C Compiler

Post by Gez »

So, is this the thread where I can recruit somebody to write an ACS decompiler for SLADE? :p
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [WIP] DH-acc: ACS C Compiler

Post by Blzut3 »

Gez wrote:So, is this the thread where I can recruit somebody to write an ACS decompiler for SLADE? :p
Given that I think DH-acc and my own compiler both have assemblers (not to mention different languages altogether), I think any hope for a usable decompiler is lost at this point. :p Eventually I'll have a disassembler that you could use though.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: [WIP] DH-acc: ACS C Compiler

Post by DavidPH »

printz wrote:I'm gonna be a bit cynical and ask what projects so far are demanding a more flexible BEHAVIOR compiler, like this one...
My project Reverse Invasion was put on hold for want of a better acc. However, that question in general is why I started this thread, so I could find out what things people actually run into. In the hopes that such things fall within the realm of DH-acc to help, of course.

And DH-acc has an old assembler used to test some of the really basic components of the compiler from before I wrote DS. I don't know if it actually works anymore, though. As for decompiling, for just acc it's not too difficult, but the thing about DH-acc at least (and I would hope acc++) is that certain aspects of codegen are configurable. For example, I'm currently working on optionally supporting ZDoom's new-found ability to pass 4 variables to a script, but part of that will be working towards enabling an alternative calling convention that uses entirely automatic variables for script args. (There is a similar intention for functions, whose args are currently all autoreg. (Because Hex++.))

A disassembler would be an interesting addition to DH-acc, though. </blatantlyrippingoffacc++> :P
Gez
 
 
Posts: 17635
Joined: Fri Jul 06, 2007 3:22 pm

Re: [WIP] DH-acc: ACS C Compiler

Post by Gez »

Blzut3 wrote:Given that I think DH-acc and my own compiler both have assemblers (not to mention different languages altogether)
They both still make ACS bytecode, so regardless of the syntax of the source language, it should be possible to turn the bytecode into something that can be understood by someone familiar with ACS.

For ACSE and ACSe, I don't know, but ACS\0 at least can be decompiled nicely with good old DeScript.
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [WIP] DH-acc: ACS C Compiler

Post by Blzut3 »

Gez wrote:For ACSE and ACSe, I don't know, but ACS\0 at least can be decompiled nicely with good old DeScript.
IIRC DeScript only works well for scripts generated by Raven's version of ACC. A decompiler for ACC can be written relativly easily due to the fact that it doesn't do any form of optimization, so you can pretty much reverse the process 1-to-1. I'm sure I could easily write a piece of assembly code that trips up DeScript but runs in Hexen if you really want an example.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: [WIP] DH-acc: ACS C Compiler

Post by DavidPH »

Just a quick status update. I have added the previously mentioned ability to configure calling convention. More importantly, I have added function overloading! Yay! Well, I added it a few days ago, but now I have fixed up the resolution code so that it is pretty much C++'s rules. (I think. If anyone discovers holes in it, let me know.)

However, in preparing to add type-based name-mangling I realized that this is something that could become relevant for cross-compiler compatibility. So before I commit to any specific rules, I would like to hear suggestions. (Especially from Blzut3 (or anyone else working on an ACS-bytecode compiler), of course, but any wisdom on the matter would be appreciated.)

In the meantime, overloading should be restricted to functions with internal linkage. (__function, not __extfunc.)
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: DH-acc: ACS C Compiler

Post by DavidPH »

OK, wow, looking at the last post... DH-acc has made significant progress. Like, as in a lot. Syntactically and semantically. I can't really come up with any sort of list other than to note that I successfully ported The Eternity Engine's z_zone.c to DS with very little trouble. (It's available as an included library, too.)

Since people on IRC are actually using this thing, though, I figured I should mention on the forum that it's still alive and getting better. Updated first post with the note that precompiled binaries are available on IRC.
User avatar
Apothem
Posts: 2070
Joined: Sat Nov 29, 2003 7:13 pm
Location: Performing open heart surgery on an ACS compiler.

Re: DH-acc: ACS C Compiler

Post by Apothem »

Good to hear things are still progressing with this project! I look forward to messing with it more in the near future :D
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

Re: DH-acc: ACS C Compiler

Post by ibm5155 »

sqrt, log, atan, pow...
You can do that on the actual acs '-'

Just now that i can do magics on acs :p
One thing that i would like to see is the float type (fixed point are nice, but you´ll be care much more than in a float type) and structs
User avatar
TheDarkArchon
Posts: 7656
Joined: Sat Aug 07, 2004 5:14 am
Location: Some cold place

Re: DH-acc: ACS C Compiler

Post by TheDarkArchon »

ibm5155 wrote:sqrt, log, atan, pow...
You can do that on the actual acs '-'
Good thing that those aren't selling points, aren't they?
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: DH-acc: ACS C Compiler

Post by DavidPH »

Just popping in real quick to mention that I have finally made progress towards the original goal of the project: An ISO C compiler. Said progress comes in the form of being able to compile C code. Current plan is to support C11 + Embedded C + special sauce*.

* Special sauce may actually just be custom C extensions to support exotic ACS-VM functionality. DO NOT EAT DH-acc. Ask your doctor if DH-acc is right for you. If you experience compulsive semicolons and underscores, discontinue use immediately and seek the warm** embrace*** of fire. If it is not possible to locate fire, or user is not flammable, the results are undefined. THIS PRODUCT IS NOT A TOY. The remainder of this message is implementation-defined****.

** Actual warmth of fire is unspecified, except that it shall be sufficient to ignite***** an object of at least sizeof(intmax_t) bytes.

*** Type of embrace is implementation-defined.

**** The implementation may choose to have no further message.

***** The alignment of the resulting inferno is unspecified. It is intended the implementation will choose Chaotic Neural, or other Chaotic type.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

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.)

Return to “Creation, Conversion, and Editing”