I switched efforts for now from a C compiler to a much simpler FORTH compiler, and to test it out I made Snake (How original of me right?)

Anyways, here's a screenshot


Currently it (the compiler) isn't in a state that's really useable to people other than me, but I hope to be fixing that in the next 1-2 weeks by breaking it out into its own project, cleaning up the repo, adding documentation, making it controllable with command line arguments, maybe making some pre-compiled binaries.
I'm also planning to add more optimizations to it.

However in the mean time if you think you can get it to work on your own, head on over to https://github.com/unknownloner/calccomp/
run ./compile.sh to compile the code, and run ./calccomp to compile "SNAKE.forth" to "FSNAKE.8xp", edit Main.hs to change the input/output files.

Also here's the code. You may notice I changed the way word definitions are done from standard FORTH, as well I have 'RECURSE' which jumps to the top of the word, or to the 'RECURSEPOINT' in the word if it exists, but I don't have any other form of looping right now.

In understanding the ASM words, know that the only thing on the stack when they run is the program data, no return addresses.

Code:


And if you just want to test the program, download from
http://z80.unknownloner.com/FSNAKE.8xp
No DoorsCSE required.

Amazing work, i love the speed!

Working on languages that are simpler than C for your first compiler is absolutely the correct decision. Are you doing something sensible with tail-calls, or are recursive loops going to blow out the stack? Or does "recurse" not touch the stack at all and really just is being used for jumps?

Every routine (except those written in assembly) have 2 labels, one for the very start of the routine which takes care of the call stack, and one right after. Here's an example:

Code:


If the "RECURSEPOINT" word appears anywhere in the definition, the recurse label is put there instead, like so:

Code:


"RECURSE" just compiles down to an unconditional jump to that label.

Although, on the CSE the FORTH return stack is a page of ram at 0x4000-0x7FFF, so really you could call a word within itself around 8000 times with no worries other than running into your variables eventually . Obviously though RECURSE is the faster and better option.

Also, now that I'm thinking about it, it would be pretty trivial to implement a conditional RECURSE (and useful too), so I think I'm going to do that. IFRECURSE maybe.

I'm impressed that you've made a third-party compiler that can actually compile code into useful programs for a TI calculator. That has long been the major sticking point of porting other languages to graphing calculators (the uttering of which causes me to glare at Antelope and its perpetually-mutating grammar). I'm suitably wowed by your demo, of course, and I look forward to continuing progress on this project.

I'm going to take a moment here and explain how the ASM code generation works for anyone interested.

Before beginning, if you aren't aware, FORTH 'words' are like routines or functions. They're a block of code which can be called from somewhere else. Also, the STDLIB consists of all of the pre-defined operations that FORTH programs can build off of. Most of them are standard FORTH operations, although some are conveniences I've added, like "DI" and "EI", so you don't need to write an ASM word just to toggle interrupts.

Skip down to the bold text if you only care about interop with other assemblers.

So, I've written an assembler which has 3 stages
Preprocess -> Parse -> Assemble

The interesting part is that haskell lets me write 'quasiquoters' which can parse arbitrary code at compile-time of the program, and output expressions (or data). I've created a quasiquoter which I've used to great effect which parses z80 assembly and outputs the resulting list of ASM expression data. This has 2 advantages.
1. I can get syntax errors from my assembly when compiling
2. I can easily include the result of arbitrary haskell code in the ASM.

For example: I might write this to load a value or label's address into HL

Code:


This makes code generation simple as writing inline assembly for the pre-defined words I want. If you'ld like to see the details, go ahead and read the code (although be warned, it's a bit of a mess right now IMO. I'm going to be cleaning it up), but the gist of it is that the compiler goes through and compiles all FORTH expressions like so:

Numeric constants are simple:

Code:

String constants are similar. No matter how many times a string occurs, it's data is only output once. A string expression compiles to

Code:

A few FORTH words (IF, ELSE, THEN, RECURSE, RECURSEPOINT) are special cased to check the current state for things they need
At this point, we're left parsing an arbitrary token. If it matches any STDLIB words, code will be generated for that word (or calling it for non-inline STDLIB words). Otherwise, if it matches any defined variables, it compiles to

Code:

Finally, if it matches none of the preceding conditions, it will compile to calling the word named by that token. It doesn't actually check if that word has been defined, so right now if you try to use a word without defining it you will get a very cryptic error message like 'Unknown label: CTRL_13', which I'm hoping to resolve.

All ASM outside of words are output sequentially at the start of the program, and then all word definitions are output after it. Non-inline STDLIB word definitions come last, although luckily only the ones you actually use have code generated.
The resulting code structure is
VAR_DEFS
CODE_PRE (setup stack, ram pages)
CODE
CODE_POST (restore stack, ram pages to previous state)
WORD_DEFS
STRING CONSTANTS

After the assembly is generated, there are a few optimization passes which occur. The primary and most important ones are:
Occurrences of "push hl \ pop hl" are removed entirely
Occurrences of "push hl \ pop de" become "ld d, h \ ld e, l" and vice-versa.
This covers most of the low hanging fruit as far as optimizations go, though I have some more complex ones planned. Right now these optimizations are applied to ALL the ASM code, not just generated FORTH code, so it affects inline ASM too. However, I'm going to be switching it to only passing over FORTH code, that way people writing ASM know that what they write is what they get, and also it lets me do optimizations based on known behaviour of the generated code, like turning "push hl \ pop de" into "ex de,hl"

Interop with other assemblers
Since the parsing step is separate from the assemble step, it has no limits to what directives it can parse. Also, it knows how to print itself back into a string representation. This means that if, when writing inline assembly for FORTH words, you want to use features of other assemblers like BRASS, you can, just by writing the output assembly to a file and assembling it yourself.

There are a few limitations to that however.
The first is one which I believe I can easily fix: My parser doesn't allow defining of labels with '@', and it doesn't handle relative label jump syntax from brass, i.e.

Code:

The second is one which would take more work to fix and currently limits you to using my assembler or brass: I rely on .varloc and .var in the FORTH compiler for variable allocation, so if you use an assembler which doesn't support that you're out of luck.

This is useful. It's also not recursion, it's just a goto. Please don't call it recursion, because that implies things you're not doing (like stack frames).

Suggest a better name and I'll use it

Edit: Thoughts on 'RESTART' or 'AGAIN'?

EDIT2:
Take this with a grain of salt as I just woke up and haven't eaten yet, but...

So I'm thinking of changing RECURSE to actually do proper recursion, so if it's the last piece of code in a word it'd jump to the start, otherwise it'd either call the start, or give you an error saying that it couldn't optimize it to a jump (compiler flag for if you only want tail-call optimizable code).

Then, take the current function of RECURSE and rename it, since it is useful to be able to restart anywhere in the word, (see my food gen code). Honestly right now I'm leaning towards RESTART.

Not going to add full-blown GOTOs though since those can cause all manner of problems .

As for when RECURSE could be optimized, there's really 2 scenarios:
1. It's the last word in a word definition
2. It's the second to last word, and the last word is THEN.
So that's pretty simple.

I do think that having a definable RECURSEPOINT be a thing is useful, since that way someone that wants to set up some initial conditions before recursively solving a problem doesn't need the overhead of two separate word definitions. When adding RESTART, I'm not sure if I should add a separate RESTARTPOINT for it, or just have it jump to the RECURSEPOINT. Opinions on that would be appreciated.

. . .

On a different subject, would it be useful to define a word as INLINE? It should be simple to implement, but for anything other than simple definitions I feel like it'd be more of a trap, bloating people's program sizes for not a whole lot of speed gain. I could see it being a little more useful to define an ASMWORD as inline though.