Well, it was 16 years since I wrote most of this so my memory is a bit fuzzy...
The stack and heap are both stored in an external 32kB SRAM. The stack is accessed simply by pushing and popping using the JVMPush and JVMPop routines around line 4553. The CPU is 8-bit, bit the JVM is 16-bit, so everything takes two operations to write both bytes. You can see the stack frame format at line 48.
Java objects and arrays are allocated on another stack that acts as the heap. Objects are allocate only - they are never freed. This isn't as big a deal as you might think since in embedded applications the code tends to just repeat the same operations over and over so you write your code to reuse the same instances instead of allocating new objects (which is slow anyway).
_do_new on line 2044 allocates a new object. Arrays are allocated at line 1991 in _l_j_newarray.
The nice thing about the JVM (at least version 1 which this implements) is that there are not many variations on operations - and if you statically link you can reduce some of the variations to common cases too.
I had a hunch it might be like this. The embedded Java I did on the Dallas part was using fixed sized arrays.
I'd actually love an annotation for Python that ran it under the null-collector. Lots of times in short run or steady state programs one doesn't generate any garbage and the constant GC or ref count over head could done away with.
Did you look @ the Bob language? It was the spiritual seed for Java by David Betz http://www.xlisp.org/
The stack and heap are both stored in an external 32kB SRAM. The stack is accessed simply by pushing and popping using the JVMPush and JVMPop routines around line 4553. The CPU is 8-bit, bit the JVM is 16-bit, so everything takes two operations to write both bytes. You can see the stack frame format at line 48.
Java objects and arrays are allocated on another stack that acts as the heap. Objects are allocate only - they are never freed. This isn't as big a deal as you might think since in embedded applications the code tends to just repeat the same operations over and over so you write your code to reuse the same instances instead of allocating new objects (which is slow anyway).
_do_new on line 2044 allocates a new object. Arrays are allocated at line 1991 in _l_j_newarray.
The nice thing about the JVM (at least version 1 which this implements) is that there are not many variations on operations - and if you statically link you can reduce some of the variations to common cases too.