rachel/secd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

add some more ideas

Browse Source
This commit is contained in:
Rachel Lambda Samuelsson 2021-12-19 11:28:46 +01:00
parent 3d9b674401
commit 75f49ac9cb
2 changed files with 44 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Makefile
View File

@ -1,7 +1,7 @@
.POSIX:
.PHONY: all debug run clean
DEPS=src/main.o src/util.o
LIBS=-lgc
LIBS=-lgc -lgmp
DBGFLAGS=-Og -g
DBGBIN=secd_debug

47
doc/ideas.md
View File

@ -18,11 +18,20 @@
* Integers
* Floating point numbers
* Raw bytes
* Lists (cons linked list), efficient map and foldr builtin would be really nice
* 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
@ -34,8 +43,7 @@
# 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?
* 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.
@ -47,4 +55,35 @@
* It's possible one might be able to JIT compile some stuff?
# Ideas
# Encoding stuff
* Constant size 2 byte instructions (not including operands)
* 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.