90 lines
3.9 KiB
Markdown
90 lines
3.9 KiB
Markdown
# Goals
|
|
|
|
* Be an efficent compilation target for typed lambda calculi
|
|
|
|
* Be substantially easier to translate to than machine code.
|
|
|
|
* Run cross-platform on as many operating systems and architectures as possible. (bare minimum 32-bit).
|
|
|
|
* Allow for code completely independent of the host machine.
|
|
|
|
* Leave memory managment out of the question for the compiler writer.
|
|
|
|
* Provide significant IO functionality.
|
|
|
|
* Provide efficient native methods for manipulating commonly used types
|
|
* Strings (don't represent as a list of characters, god)
|
|
* Characters
|
|
* Integers
|
|
* Floating point numbers
|
|
* Raw bytes
|
|
* Lists (cons linked list), efficient map, foldr, and filter instructions would be nice
|
|
* Arrays (constant lookup continous memory)
|
|
|
|
* Have methods for representing algebraic data types built into the machine.
|
|
* Sums and products of arbitrary size, and methods for (de)constructing them.
|
|
* Sums as tagged pairs since the machine is untyped
|
|
|
|
* Instruction for tail recursion which takes the new parameters of the stack and resets the C pointer to where it last entered a closure.
|
|
|
|
* Recursion instruction which functions as dup : app
|
|
|
|
* GMP arithmetic
|
|
|
|
* Some sort of pattern matching facility for matching on the first element of a pair, (the constructor).
|
|
|
|
# Non-Goals
|
|
|
|
* Safely error out or leave catchable exceptions when instruction is called with wrongful operands.
|
|
|
|
* Dynamic linking, creating object files with polymorphic types.
|
|
|
|
* Lazy evaluation.
|
|
|
|
# Nicities (plausible)
|
|
|
|
* Provide a compiler from a simply typed lambda calculus, coupled with a small standard library which would confirm type safety of all used instructions. Maybe go even further? System F?
|
|
|
|
* Maybe some vector operations? You could reasonably operate on chunks of the stack.
|
|
|
|
# Nicities (dreaming)
|
|
|
|
* Provide more complete IO functionality, such as networking, etc. (this is not likely to happen)
|
|
|
|
* Provide some sort of FFI (this is not likely to happen)
|
|
|
|
* It's possible one might be able to JIT compile some stuff?
|
|
|
|
# Encoding stuff
|
|
|
|
* Common instructions are 1 byte and a lookup table is used to run a function executing said instruction. Less common instructions will have the first byte take them to a function which reads the next byte, allowing for a tree of instructions.
|
|
|
|
* All words realistically **have** to be the same size for the stack to make sense. Which size should be used? This feels like it could easily become machine dependant.
|
|
* Possibly go for the highest you have, 8 bytes? Would mean that performance would be god awful on 32 bit machines. I might be ok with that? Am I?
|
|
* What about byte types, etc? Should we really allow that? It becomes a pain. Perhaps it is easiest to pretend computers do not exist and only deal with numbers? Only use GMP arithmetic then?
|
|
* Possible set of builtin types:
|
|
* Int64 - 64-bit signed integer
|
|
* Word64 - 64-bit unsigned integer
|
|
* Float - 64-bit double precision floating point number
|
|
* Integer - GMP
|
|
* Natural - GMP
|
|
* Float - GMP
|
|
* Rational - GMP
|
|
* String - Like Data.Text
|
|
* Char - 64-bit unicode codepoint.
|
|
* List - Pointer to linked list
|
|
* Array - Pointer to length tagged constant memory
|
|
* Pair - Pointer to constant memory of length 2
|
|
|
|
# File Format stuff
|
|
|
|
* Much like ELF, start of with header containing basic info, reserve some bytes for future additions, have field specifing version. Then have sections.
|
|
|
|
* Code section, the initial C stack.
|
|
|
|
* Global section, the initial G env.
|
|
|
|
* Linkable and Executable. Linkables have some sort of symbol table for wanted symbols, as well as a list of files it wishes to link with. The linker, or perhaps the VM, when loading, will then lookup these files in a global search path, perform substitution with the symbols to create an Executable file with a complete global table.
|
|
|
|
* Must realise an encoding for closures, products and GMP numbers to be used in globals.
|