Here's another alpha release of Neolithic for those of you ambitious enough to grind thru figuring out how to use the compiler and what it can and cannot do.  This should be more usable than the last version, as I've recently added direct binary generation.  And I remembered to turn off the "debug" code that botched up the first (subtle) alpha release.

Included below is a zip file containing both a Windows and a MacOS executable.  It's a command line program, so you need to use either Command Prompt (in Windows) or Terminal (on MacOS) to run it.

To run, use one of the below lines followed by the file to compile:

    neolithic.exe     (in Windows Command Prompt)

    ./neolithic-mac  (in MacOS Terminal)

Make sure everything is in the same directory when you compile.  Source file(s) should end with the ".c" extension.

The compiler outputs an ASM file (DASM compatible), a BIN file (4K Atari 2600 binary), a SYM file (symbol table compatible with Stella) and a bunch of AST files (abstract syntax tree files for each source file #include(d)).

If you're looking for documentation, I don't have any good documentation yet.  I have a quick little write-up, but it really needs to be filled out more.  If you have any questions, please ask, as that will be the easiest way for me to know what needs documenting.

The Congo Bongo demo source code included below is probably you're best bet for figuring things out.

---

Some notes of what I've been working on:

The big user feature for this release is the direct binary generation.  DASM is no longer necessary as the compiler can generate a binary file that can be used in Stella.

Besides the direct binary generation, the other big feature is function call tree analysis.  I implemented this feature to be able to:

  (1) track function usage - whether a function is used or not, whether it can be inline-d or not, etc.

  (2) track overall call depth - to know where the zeropage RAM ends and the stack begins (very important on the 2600)

  (3) statically allocate stack frames - allocate local variables based on absolute memory locations vs. stack relative locations

The feature is not fully complete, but I'm going to push the code generation more in this direction.  Using statically allocated frames instead of stack seems to be the right way to go, as the lack of stack ops on the 6502 tend to minimize the usefulness of a stack-based approach to function arguments and complex expressions.

The compiler still does not fully support 16-bit ops... mainly because I have to switch up how the expression processing and code generation work.  I'm currently using both the A and X registers to do this, but that doesn't seem like the right idea... This is where having a second accumulator register would come in handy.  I'm thinking I might need to switch to utilizing my memory-based 16-bit accumulator I've created for the multiply op support, or maybe even adding in more temporaries as needed... Which leads into flattening the expression trees during code generation, which is something I've already started working on the code for.

Part of the stall-out with 16-bit support comes from me not really needing robust support yet in any of my own Neolithic-based projects.  I'm too good at avoiding and working around the issues/shaky support of this feature in the compiler.  With the 6502, I found it's better to favor array constructs over pointer ops; then only using pointers to set a base offset into an array of data... and then accessing that data with array operations.   i.e.  set spriteFramePtr to point to current sprite frame, then use spriteFramePtr[y] to access the data. 

Which makes me wonder if Pascal would have been the better language to base this language on.  Hmmm...

-----

Anyways...

Enjoy.

Neolithic-v0.2alpha.zip congo_c_2021_08_15.zip