ZDoom

Crazy stuff, but why am I posting here when I can't use this anyway.

Gez wrote:We've got to go deeper.

Engineception.

I'm gonna be a bit cynical and ask what projects so far are demanding a more flexible BEHAVIOR compiler, like this one...

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?

So, is this the thread where I can recruit somebody to write an ACS decompiler for SLADE?

Gez wrote:So, is this the thread where I can recruit somebody to write an ACS decompiler for SLADE?

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. Eventually I'll have a disassembler that you could use though.

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++>

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.

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.

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

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.

Good to hear things are still progressing with this project! I look forward to messing with it more in the near future

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

Just now that i can do magics on acs
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

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?

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.

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. (New features of GDCC are mentioned in the updated first post.)