138 lines
5.1 KiB
Org Mode
138 lines
5.1 KiB
Org Mode
* Languages / VM Notes about implmementations
|
|
** Instruction Order
|
|
*** Prefix
|
|
- Lisp like feel
|
|
**** Pros
|
|
- Easily parses into AST
|
|
- Easy to generate macros
|
|
**** Cons
|
|
- Unintuitive to beginners
|
|
- Hard to code read for begineers
|
|
*** Postfix
|
|
- Forth like feel
|
|
**** Pros
|
|
- Trivial to parse
|
|
- Generally small codebase
|
|
**** Cons
|
|
- Unintuitive to beginners
|
|
- Hard to code read for begineers
|
|
*** Infix
|
|
- Pretty much all others
|
|
**** Pros
|
|
- Intuitive to beginners (math like)
|
|
**** Cons
|
|
- More complex to parse
|
|
** Virtual Machine abstraction
|
|
*** Accululator
|
|
A single slot where all intermediate calculations get stored to
|
|
**** Pros
|
|
- Very simple
|
|
- Easy to implement
|
|
- Trivial to abstract
|
|
**** Cons
|
|
- Very slow due to instruction bottlenecks
|
|
*** Stack
|
|
A Last in First out, usually 2 stacks 1 operation and 1 return stack
|
|
**** Pros
|
|
- Simple to implement
|
|
- Parser trivial to build
|
|
**** Cons
|
|
- generally a stacic size, so recursion is usually unsafe.
|
|
*** Register
|
|
A set of very fast accumulators
|
|
**** Pros
|
|
- Very fast
|
|
- Closest to modern hardware
|
|
- Easy to JIT
|
|
**** Cons
|
|
- Extremly complicated
|
|
- Very tied to 'modern' hardware so hard to abstract
|
|
*** Memory to Memory
|
|
Operates on pointers to memory, everything exists in memory.
|
|
**** Pros
|
|
- Most flexable for dynamic allocation
|
|
- Easy to understand conceptually
|
|
**** Cons
|
|
- Likely slower than stack and register
|
|
** Memory abstractions
|
|
*** Manual
|
|
Manual memory management is where the language gives the developer tools to
|
|
allocate, deallocate, and move memory but does not manage logic.
|
|
**** Pros
|
|
- Simpler compiler
|
|
- Fastest
|
|
**** Cons
|
|
- Cognitive load on developer
|
|
- Higher chance of bugs due to mistakes
|
|
*** Garbage Collected
|
|
GC usually uses a 'mark and sweep' method where the programs 'vm' searches for unused blocks of memory and reclaims them.
|
|
**** Pros
|
|
- Developer does not have to worry about memory
|
|
**** Cons
|
|
- Non-deterministic pauses
|
|
*** RAII
|
|
Resource acquisition is initialization
|
|
Heap values are tied to the scope they are created in, complex rules allow for moving, coping, and borrowing memory allocations.
|
|
**** Pros
|
|
- If rules are followed creates much safer code than manual memory
|
|
- Deterministic
|
|
**** Cons
|
|
- Extremly complex memory rules that need to be followed by developer.
|
|
- Slow compilation due to static analysis of memory rules.
|
|
*** Arena
|
|
An arena is a block of memory where a series of allocations get grouped together.
|
|
It is a logical extension of manual memory managment where you allocate to an arena.
|
|
When an arena is freed all allocations are freed as a single block.
|
|
**** Pros
|
|
- Deterministic
|
|
**** Cons
|
|
- Developer still needs to think about memory
|
|
*** Stack based
|
|
All values are either pre-allocated at compile time or they grow with the stack being free'd when the scope ends for that scope.
|
|
This is how 'mission critical' software works like at NASA.
|
|
**** Pros
|
|
- Deterministic allocations
|
|
- Memory is freed when a scope ends
|
|
**** Cons
|
|
- Cannot allocate dynamic memory
|
|
- Very strict rules
|
|
*** Frame based
|
|
All memory used by the program exists in one big bump allocator.
|
|
When a function gets called, it creates a new arena in memory starting at the end of the previous frame. (or at the beginning of memory if no function has been called)
|
|
Variables allocated in the frame's arena are owned by default by the frame they are allocated in.
|
|
When variables get modified within the current frame they will get updated in that frame in their current location in the arena.
|
|
If the size of the variable changes (like adding a value to the end of a array), a link is added to the internal list that points to a new block is allocated
|
|
at the end of the arena of the size of that value, so they are variable sized blocks
|
|
When a variable is passed to a child function primitive types are pass by value, complex types (Arrays, Plexes, Strings) are pass by reference.
|
|
Variables passed as arguments to the child follow the same rules except when the size of a complex type changes, then a new value is added as a link
|
|
from the parent to the child and the new value is allocated at the end of the childs arena (but the owner is still the parent).
|
|
When a function "returns" the frame is deallocated and all values allocated by it is freed; thus freeing memory deterministically.
|
|
Only a single variable may be returned from a function. When a variable is returned if it is primitive it is just passed back to the parent.
|
|
If it is complex the value is coalesced into a single contiguous values and the link in the parent is updated to point at the "new" end of the arena.
|
|
If the parents block is at the end the entire block is coalesced into a single contiguous block.
|
|
**** Pros
|
|
- Deterministic
|
|
- "simple" from the computers POV
|
|
- Allows for dynamic memory allocation
|
|
**** Cons
|
|
- Not flexable in memory method
|
|
- Likely slower than RAII
|
|
** Computer abstraction
|
|
*** Von Neumann
|
|
Code and data exist in the same block
|
|
Example is the Uxn/Varvara VM
|
|
**** Pros
|
|
- The most "free" compiler
|
|
- Very simple to emit commands
|
|
**** Cons
|
|
- Need to "jump" over data to avoid it being run as commands
|
|
- Functions need to be declared after the "main"
|
|
*** Harvard
|
|
Seperate code and data
|
|
Most other VMs use this
|
|
**** Pros
|
|
- Safer because code is not operatable
|
|
**** Cons
|
|
- More complicated compiler for one pass
|
|
- Not as flexable
|