KermM: I was suggesting essentially, don't bother with a higher level language.

Muessigb: It looks like you're implementing a lot of the lexing and parsing by hand. I would *strongly* suggest you

1. Write down a proper grammar, to act as ground truth for your parser
   
2. Use something like Antlr4 to implement the compiler
   

Some specific questions regarding your language design:

• What are your scoping rules?
  
• Do you only support first-order functions? If not, do you plan to work with bare function pointers, or implement support for some kind of closure?
  
• Assuming you support dynamic memory allocation, what malloc implementations are you considering? If you're implementing closures and/or some type of automatic memory management, what garbage collection algorithm will you use?
  
• What model of typing do you intend to use? Will you support some form of polymorphism?
  
• Do you intend to support recursion (either direct or indirect)?
  

Some specific questions regarding compiler design:

• What sorts of optimizations will you apply, or will you rely entirely on the VM to perform JIT optimizations?
  
• Will you support tail-calls?
  
• What control structures will a switch/case, or equivalent, compile down to?
  
• What is your function calling convention? Is it caller saves, or callee saves?
  

I am sorry, but I cannot answer many of your questions as I am only helping with the compiler.
Cumred_Snektron is doing most of the compiler development and he will not start over.
I will be doing most of the VM and I do a big part of the overall language design.

Scoping will be per block. Variable live until the end of a block or in assembly until they are freed (you can only free the last created one).

No garbage collection, but when leaving a block all variables of it are deallocated.

Recursion will be supported up to a certain level.

Most optimizations will be done by the compiler.

There is only "if ... elseif ... elseif ... else ... end" which will translate into conditional relative jumps.

Callee saves.

So it sounds like you're only supporting stack-based allocation of variables. Are you familiar with the (severe) limitations of this approach, from a performance standpoint?

This will work alright. We have enough MHz to deal with that.

Also we made a huge hardware change last night. We dropped SD card support and upgrades the processor to support external RAM and flash. The microcat will now contain 16MB built-in NOR flash and will be able to run C games too.

EDIT: I think we will either go back to the old SD card way or have flash as modules so that it can be replaced or upgraded. Like having a high speed board to board interconnect and having another PCB stacked (we have the space) and the flash chip(s) soldered on that. Then the flash could be replaced or upgraded by buying a new module (which would be reasonably cheap).

It's not just CPU overhead, it's also memory bandwidth, and you horribly restrict your ability to use reference types (they can never pass outwards).

How would games be loaded in the new SD-less model, assuming you don't revert?

From the memory mapped flash. I would format it with a file system that has continuous blocks and use claw by streaming from it and executing assembly programs by jumping to them directly.

OK, its decided. We will go back to the original SD based solution and go back to the 50 cents cheaper, but smaller processor that we had in mind before the Flash idea.

And how will that affect the program architecture? Will you be returning to the language and/or program specifying which components of the program should be in RAM at any given time?

Well I don't understand you. But we will as we would always have, kept Claw as a language. C might be added by us at some point or has to be done by the community.

If you were going to have more memory (namely external RAM), I expected that you would fit entire programs in RAM. It sounds like you're back to a system where you can only page parts of the program into RAM at once.

Well first, Claw was always designed in this way and it's one of it's greatest features that it's pipeline streamed from the SD card. About C, it's always loaded into RAM completely.
We don't have pages of RAM or flash as it's all mapped into the 4GB address space.
About RAM, it cannot be extended at all.

I forgot to answer that. So we don't have references at all. And we have ways to swap stack entries to pass values back that are created inside a function.

Yes, this is exactly the sort of technique I was talking about when I said you're going to have horrible memory bandwidth issues.

*bump* What's new with the MicroCat project? I haven't seen an update in a long time, and I want to make sure it's still going strong.

I have big trouble there and the Microcat is on hold. The issue is that all people who were involved stopped working on it and I was left alone financially and in terms of the huge work that needs to be done. Then I can't solder SMD chips that well, let alone a QFP64 with a 0.4 mm pin pitch.
We then also found nobody who would assemble the units and we ran finally out of money...
Maybe when time comes, we will go back to it (or me as there only is me ans Iwert left who can't help that much hardware wise). Having the problems, we started a new project that I a a little less hard to release, as it will come in a DIP form without any smd components. It will have similar specifications but it is not a handheld. I will post about it soon.