I have been working on OPIA since 2009. OPIA is the successor (and complete do-over) for Antidisassemblage (which I worked on from 2004 to 2005, and a bit in 2007). This has been on ongoing topic at Cemetech and Omnimaga, so I figured that other websites deserve a topic too

OPIA is a C-like language (functions, variables, expressions, constructs, etc.) which brings all the power of polymorphism seen in OOP languages like Java/C# to the z80 -- but in simpler terms which expose function-pointers and method-pointers more directly, but cleanly (structs implement interfaces automatically just by having the correct methods -- thus new polymorphic behavior can be added to something without any changes to the base code or to its underlying structure!).

OPIA is very focused on low-level representation: Variables, arrays, structs, and functions are designed to match raw/native representations so that they can be tied DIRECTLY into any underlying system (e.g. use OS values as variables or call system routines as functions without extra overhead -- it's 1-to-1). Everything is designed to be stored/coded "as it would be" in assembly. OPIA has the capability to be for z80 what C is for larger systems.

OPIA will use Data-flow analysis and Liveness-Analysis, etc., to trace values through the code and precompute/optimize it as much as possible -- So go ahead and use a loop to initialize that array, and the compiler will convert it an embedded value. In addition, you can use the $ operator to REQUIRE this (and cause the compiler to take more liberties) and, for example, tell the compiler to interpret a function and embed the result as a value.

The compiler will be in Java (already started) as a command-line interface. However, it will also be modularized as a java API so that other tools can be made for the language which use the compiler to build/analyze code (Tokens, Abstract syntax trees, Optimization, Compilation, etc.) -- This means things like Notepad++, or new tools like a visual (rather than textual) code editor.

Rather than providing "everything you need" in one package, OPIA only provides core features and must be compiled on your computer. However, unlike those all-in-one packages (which are amazing, btw), OPIA can be expanded and integrated for anything and everything z80. I will be writing the core compiler (which is viewable at google code), but everyone else will have the chance to expand the language via includes/libraries/etc.

There's been a ton of discussion already, but if anything picks up here, I will try to post some summaries of past discussion -- the language design is being made concrete before I get too deep into making the compiler. Discussion will continue in forums, but official documentation of what the language "IS" so far can always be found at:

http://tinyurl.com/z80opia

THE TIME HAS COME! (the walrus said) ... I have reviewed all comments, topics, posts, etc. all the way back until before I switched the language to a "Go-ish" layout, and I finally feel that OPIA is fully (syntactically and semantically) defined and decided (or at least, as much as it can be before it is coded) -- which I wanted to do before I did anything huge with the compiler.

My plans (when time permits between school, work, moving, and my soon to be first-child) are as follows:

(1) lay out a careful plan for the compiler pipeline/design. This has already been 90% grasped in my head alone (after having poured over compiler books and articles and mental experiments "for fun"), but I have recently re-read most of the chapters in Modern Compiler Implementation In Java (it's the BEST!), and been charting out a careful comparison of my design versus what everyone else swears by -- and it turns out that I am not deviating terribly much. Expect an analysis and layout of the plan from me in the future (I have it mostly set).

(2) Update the Language Overview as much as I see fit (I don't want to be too picky with it, but I do want to make sure that every aspect is well documented so nothing falls through the cracks).

(3) Jump into the coding. I will keep everyone updated as that progresses. The exciting thing is that I will release it in modules, so that you can see everything up to the tokenizing & preprocessing (this is it's current state, though I may rework that a bit to be SLIGHTLY more modular), parsing/tree-building, etc. Every aspect of the pipeline will be explained, as in (1).

Anyone is welcome to ask questions about anything they think is lacking or confusing, and I am still open to considering some changes/additions; but I don't foresee anything that would change the language enough to put of coding it now.

Side note: as for interpreted aspects, the default will be to precompute as much as possible without unraveling loops or recursive calls (unless the contents clearly have no runtime side-effects), and that the $ operator will be "deep"/recursive, causing a thing (and ALL of it's contents, except for references to externally defined entities) to be fully precomputed.