You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Experimenting using GH Discussions for a public devlog,
Current main goal is self-hosting via transpiler to C: a metric ton of things have been postponed until self-hosting works, mainly because I don't want to implement changes in parallel to bootstrap host and the real thing.
After instantiation of runtime classes works (almost there) I should be able to get to working on making the evaluator transpile cleanly.
Only major issue I foresee is the different object model of boostrap host vs self-hosted version, which manifests in things like different method signatures in direct Class methods, etc.
I'm sure I will there will be a few surprises, and bugs in the transpiler, though...
After self-hosting there needs to be some consolidation and refactoring.
Next major milestone following self-hosting is a lower level IR and optimizations. (For initial convenience the transpiler works directly on the AST, but doing almost any optimizations on it is just too painful. This may have been a mistake, but it made sense at the time...)
Main optimizations I want to implement at this stage are all about lowering high level OO code "basic C-like level":
Static linking of known methods so they don't need runtime dispatch (in presence of concrete class information)
Eliminating redundant typechecks
Collapsing chains of trivial known methods (special case inlining for methods that just send a single message using only receiver and arguments)
Generate reasonable code for Boolean branches and loops
Generate reasonable code for array iteration
Generate reasonable code for interval iteration
Support for raw slots and user defined immediates
These should be enough to tell me if I'm completely off base with my assumptions about being able to combine typed Foolang decently...
Assuming that holds, Foolang should then be good enough for writing a VM for itself.
Why a VM?
Because Foolang is intended to be a live environment, but is also intended to have deeply immutable globals. Inside a VM we can allow mutation of the global environment from outside the global environment in a principled manner: if a slot is added to a class, we can stop everything, find all instances of the redefined class and change them to the new shape, etc.
"Trust me, it will work fine."
Unless it's blindingly obvious, I'm sort of dying to explain my thinking to people, or enticing others to join. ...so do say "that sounds interesting" if it does, ask questions, etc. (Just don't ask why I'm doing this: this is a passion project, not a practical endeavour!)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Experimenting using GH Discussions for a public devlog,
Current main goal is self-hosting via transpiler to C: a metric ton of things have been postponed until self-hosting works, mainly because I don't want to implement changes in parallel to bootstrap host and the real thing.
After instantiation of runtime classes works (almost there) I should be able to get to working on making the evaluator transpile cleanly.
Only major issue I foresee is the different object model of boostrap host vs self-hosted version, which manifests in things like different method signatures in direct
Class
methods, etc.I'm sure I will there will be a few surprises, and bugs in the transpiler, though...
After self-hosting there needs to be some consolidation and refactoring.
Next major milestone following self-hosting is a lower level IR and optimizations. (For initial convenience the transpiler works directly on the AST, but doing almost any optimizations on it is just too painful. This may have been a mistake, but it made sense at the time...)
Main optimizations I want to implement at this stage are all about lowering high level OO code "basic C-like level":
These should be enough to tell me if I'm completely off base with my assumptions about being able to combine typed Foolang decently...
Assuming that holds, Foolang should then be good enough for writing a VM for itself.
Why a VM?
Because Foolang is intended to be a live environment, but is also intended to have deeply immutable globals. Inside a VM we can allow mutation of the global environment from outside the global environment in a principled manner: if a slot is added to a class, we can stop everything, find all instances of the redefined class and change them to the new shape, etc.
"Trust me, it will work fine."
Unless it's blindingly obvious, I'm sort of dying to explain my thinking to people, or enticing others to join. ...so do say "that sounds interesting" if it does, ask questions, etc. (Just don't ask why I'm doing this: this is a passion project, not a practical endeavour!)
Beta Was this translation helpful? Give feedback.
All reactions