What I'm thinking about would better be called an optimizer. To be a compiler it would have to produce machine code, not just reworked assembly.

[quote]This is exactly what prompted me to come up with PLASMA: Proto Language AsSembler for Apple.[quote]Cool! I saw one of your demonstration videos about PLASMA. Are you still working with byte code? How do you split up memory usage in functions between zero page and the data stack?

Sorry, can't say I quite see the difference.

Many compilers create assembly source code. Even compiler writers realize its far easier for an assembler to create machine code than to incorporate all that in to the code generation of the compiler itself.

Naturally there are always exceptions.

This is where I diverged from the original concept of three output options: byte code, threaded code, and pure native code. The code is still on the backwaters of SourceForge: http://vm02.sf.net but I've focussed on the byte code implementation for all subsequent versions. It's pretty easy to conceptualize the byte codes as macros to be expanded in-line.

The zero page usage breaks down as a split evaluation stack indexed by X, a NEXTOP/FETCHOP that isn't needed for non-bytecode implementations, a local frame stack pointer for all the local variables, and some temps. All values are copied to the evaluations stack for processing (but caching TOS in A,Y really helps here for native code).

Dave...