Update README.md

PLASMA/README.md

@@ -11,7 +11,7 @@ All three systems were implemented using stack architecture.  Pascal and Java we
 
 ##A New Approach
 
-PLASMA takes an approach that uses the best of all the above implementations to create a unique, powerful and efficient platform for developing new applications on the Apple II.  One goal was to create a very small VM runtime, bytecode interpreter, and module loader that could adjust the code size vs. performance optimizations to allow for interpreted code, threaded code, or efficiently compiled native code.  The decision was made early on to implement a stack based architecture duplicating the approach taken by FORTH.  Space in the zero page would be assigned to a 16 bit, 32 element evaluation stack, indexed by the X register.  The stack is purposely not split between low and high values so as to allow reading and writing addresses stored directly on the stack.  The trade off is that the stack pointer has to be incremented and decremented by two for every push/pop operation.  A simple compiler was written so that higher level constructs could be used and global/local variables would hold values instead of using clever stack manipulation.  Function/procedure frames would allow for local variables, but with a limitation - the frame could be no larger than 256 bytes.  By enforcing this limitation, the function frame could easily be accessed through a frame pointer value in zero page, indexed by the Y register.  The call stack uses the 6502's hardware stack resulting in the same 256 byte limitation imposed by the hardware.  However, this limitation could be lifted by extending the call sequence to save and restore the return address in the function frame. This was not done initially for performance reasons and simplicity of implementation.  One of the goals of PLASMA was to allow for intermixing of functions implemented as bytecode, threaded code, or native code.  Taking a page from the FORTH play book, a function call is implemented as a native subroutine call to an address. If the function is in bytecode, the first thing it does is call back into the interpreter to execute the following bytecode.  Functions can be selectively expanded as bytecode, threaded code, or natively compiled, all at load time.  Threaded code expands to about 3X the size of bytecode with about 3X the performance.  Native code is about 5X-10X the size with a significant improvement in performance.  The native code compiler uses a strategy of caching the Top-Of-Stack value in the Y and A registers of the 6502.  The compiler also tracks the TOS pointer and adjusts the address accordingly to avoid actual manipulation of the X register. The X register in effect becomes the frame pointer for the evaluation stack.  Function call parameters are pushed onto the evaluation stack in order they are written. The first operation inside of the function call is to pull the parameters off the evaluation stack and put them in local frame storage. Function callers and callees must agree on the number of parameters to avoid stack underflow/overflow.  All functions return a value on the evaluation stack regardless of it being used or not.  Lastly, PLASMA is not a typed language. Just like assembly, any value can represent a character, integer, or address. It's the programmer's job to know the type. Only bytes and words are known to PLASMA. Bytes are unsigned 8 bit quantities, words are signed 16 bit quantities. All stack operations involve 16 bits of precision.
+PLASMA takes an approach that uses the best of all the above implementations to create a unique, powerful and efficient platform for developing new applications on the Apple II. One goal was to create a very small VM runtime, bytecode interpreter, and module loader that could adjust the code size vs. performance optimizations to allow for interpreted code, threaded code, or efficiently compiled native code. The decision was made early on to implement a stack based architecture duplicating the approach taken by FORTH. Space in the zero page would be assigned to a 16 bit, 32 element evaluation stack, indexed by the X register. The stack is purposely not split between low and high values so as to allow reading and writing addresses stored directly on the stack. The trade off is that the stack pointer has to be incremented and decremented by two for every push/pop operation. A simple compiler was written so that higher level constructs could be used and global/local variables would hold values instead of using clever stack manipulation. Function/procedure frames would allow for local variables, but with a limitation - the frame could be no larger than 256 bytes. By enforcing this limitation, the function frame could easily be accessed through a frame pointer value in zero page, indexed by the Y register. The call stack uses the 6502's hardware stack resulting in the same 256 byte limitation imposed by the hardware. However, this limitation could be lifted by extending the call sequence to save and restore the return address in the function frame. This was not done initially for performance reasons and simplicity of implementation. One of the goals of PLASMA was to allow for intermixing of functions implemented as bytecode, or native code. Taking a page from the FORTH play book, a function call is implemented as a native subroutine call to an address. If the function is in bytecode, the first thing it does is call back into the interpreter to execute the following bytecode. Function call parameters are pushed onto the evaluation stack in order they are written. The first operation inside of the function call is to pull the parameters off the evaluation stack and put them in local frame storage. Function callers and callees must agree on the number of parameters to avoid stack underflow/overflow. All functions return a value on the evaluation stack regardless of it being used or not. Lastly, PLASMA is not a typed language. Just like assembly, any value can represent a character, integer, or address. It's the programmer's job to know the type. Only bytes and words are known to PLASMA. Bytes are unsigned 8 bit quantities, words are signed 16 bit quantities. All stack operations involve 16 bits of precision.
 
 The PLASMA low level operations are defined as: