diff --git a/app/views/layouts/application.html.haml b/app/views/layouts/application.html.haml
index d497b2b..16b6357 100644
--- a/app/views/layouts/application.html.haml
+++ b/app/views/layouts/application.html.haml
@@ -16,9 +16,9 @@
%ul.nav
%li= link_to "Home" , root_path
%li= link_to "Architecture", "/rubyx/layers.html"
- %li= link_to "Soml (obsolete)" , "/soml/typed.html"
%li= link_to "Arm Resources" , "/arm/overview.html"
%li= link_to "About" , "/project/motivation.html"
+ %li= link_to "Misc" , "/misc/index.html"
%li= link_to "News" , blog_index_path
=link_to "https://github.com/ruby-x" do
=image_tag "x-small.png", style: "position: absolute; top: 15px; right: 15px; border: 0; width: 70px"
diff --git a/app/views/pages/misc/_menu.html.haml b/app/views/pages/misc/_menu.html.haml
new file mode 100644
index 0000000..45457fc
--- /dev/null
+++ b/app/views/pages/misc/_menu.html.haml
@@ -0,0 +1,5 @@
+.row
+ %ul.nav
+ %li= link_to "Threads (rumble)" , "threads.html"
+ %li= link_to "Optimisation (ideas)" , "optimisations.html"
+ %li= link_to "SOML (old)", "soml.html"
diff --git a/app/views/pages/soml/bench.numbers b/app/views/pages/misc/bench.numbers
similarity index 100%
rename from app/views/pages/soml/bench.numbers
rename to app/views/pages/misc/bench.numbers
diff --git a/app/views/pages/misc/index.html.haml b/app/views/pages/misc/index.html.haml
new file mode 100644
index 0000000..2b56a89
--- /dev/null
+++ b/app/views/pages/misc/index.html.haml
@@ -0,0 +1,12 @@
+= render "pages/misc/menu"
+
+%h1= title "Ideas, old and new"
+
+An idea is where everything starts. Like this project. But not every idea
+makes it to reality, and some that do do not turn out as planned.
+
+This is a collection of both, the overripe and unripe. Maybe we can learn from the
+first, and by continuously reexamining the second see if it is worth the
+effort to bring them down to earth.
+
+%h2 Unrealized
diff --git a/app/views/pages/misc/optimisations.html.haml b/app/views/pages/misc/optimisations.html.haml
new file mode 100644
index 0000000..b21fff6
--- /dev/null
+++ b/app/views/pages/misc/optimisations.html.haml
@@ -0,0 +1,33 @@
+= render "pages/misc/menu"
+
+%h1=title "Optimisation ideas"
+
+%p I won’t manage to implement all of these idea in the beginning, so i just jot them down.
+
+%h3 Inlining
+%p
+ Ok, this may not need too much explanation. Just work. It may be interesting to experiment how much this saves, and how much
+ inlining is useful. I could imagine at some point it’s the register shuffling that determines the effort, not the
+ actual call.
+%p Again the key is the update notifications when some of the inlined functions have changed.
+%p
+ And it is important to code the functions so that they have a single exit point, otherwise it gets messy. Up to now this
+ was quite simple, but then blocks and exceptions are undone.
+
+%h3 Register negotiation
+%p
+ This is a little less baked, but it comes from the same idea as inlining. As calling functions is a lot of register
+ shuffling, we could try to avoid some of that.
+%p More precisely, usually calling conventions have registers in which arguments are passed. And to call an “unknown”, ie any function, some kind of convention is neccessary.
+%p
+ But on “cached” functions, where the function is know, it is possible to do something else. And since we have the source
+ of the function around, we can do things previously impossible.
+%p One such thing may be to recompile the function to accept arguments exactly where they are in the calling function. Well, now that it’s written down. it does sound a lot like inlining, except without the inlining:-)
+%p
+ An expansion if this idea would be to have a Negotiator on every function call. Meaning that the calling function would not
+ do any shuffling, but instead call a Negotiator, and the Negotiator does the shuffling and calling of the function.
+ This only really makes sense if the register shuffling information is encoded in the Negotiator object (and does not have
+ to be passed).
+%p
+ Negotiators could do some counting and do the recompiling when it seems worth it. The Negotiator would remove itself from
+ the chain and connect called and new receiver directly. How much is in this i couldn’t say though.
diff --git a/app/views/pages/soml/syntax.html.haml b/app/views/pages/misc/soml.html.haml
similarity index 87%
rename from app/views/pages/soml/syntax.html.haml
rename to app/views/pages/misc/soml.html.haml
index 41ea81b..cf7d849 100644
--- a/app/views/pages/soml/syntax.html.haml
+++ b/app/views/pages/misc/soml.html.haml
@@ -1,7 +1,27 @@
-= render "pages/soml/menu"
+= render "pages/misc/menu"
%h1= title "Soml Syntax"
+Soml was a step on the way. While i was still thinking about VM's and c++ ,
+the year was 2015.
+%br
+I had thought that some kind of typed layer was needed, and that one could
+implement the higher level in a language. A typed language, sort of like c++,
+that would be used to implement the code of ruby.
+%br
+A little like PyPy has a core that only uses a small set of python, that can,
+a la crystal, be fully type inferred.
+%br
+This idea turned out to be wrong, or difficult. Because the bridge between the
+typed an untyped was unclear or i didn't get it to work. The current system
+works by typing self, but not it's instances. A difficult mix to express in a
+language.
+%br
+This led me to abandon soml and rewrite the functionality as vool and mom layers.
+But Soml was working, the parser is still about and there are some interesting
+=link_to "benchmarks" , "soml_benchmarks.html"
+that came from it and really validated the calling convention.
+
%h2 Top level Class and methods
%p The top level declarations in a file may only be class definitions
%pre
diff --git a/app/views/pages/soml/benchmarks.html.haml b/app/views/pages/misc/soml_benchmarks.html.haml
similarity index 95%
rename from app/views/pages/soml/benchmarks.html.haml
rename to app/views/pages/misc/soml_benchmarks.html.haml
index 7b7f0a4..22d8395 100644
--- a/app/views/pages/soml/benchmarks.html.haml
+++ b/app/views/pages/misc/soml_benchmarks.html.haml
@@ -1,7 +1,11 @@
-= render "pages/soml/menu"
+= render "pages/misc/menu"
+
+Disclaimer: read the intro of
+=link_to "Soml" , "soml.html"
+first. This is obsolete, and has only historic value.
+
%h1= title "Simple soml performance numbers"
-
%p
These benchmarks were made to establish places for optimizations. This early on it is clear that
performance is not outstanding, but still there were some surprises.
diff --git a/app/views/pages/rubyx/threads.html.haml b/app/views/pages/misc/threads.html.haml
similarity index 99%
rename from app/views/pages/rubyx/threads.html.haml
rename to app/views/pages/misc/threads.html.haml
index 1f4e7cd..83f1ba1 100644
--- a/app/views/pages/rubyx/threads.html.haml
+++ b/app/views/pages/misc/threads.html.haml
@@ -1,4 +1,4 @@
-= render "pages/rubyx/menu"
+= render "pages/misc/menu"
%h1= title "Threads are broken"
diff --git a/app/views/pages/soml/typed.html.haml b/app/views/pages/misc/typed.html.haml
similarity index 99%
rename from app/views/pages/soml/typed.html.haml
rename to app/views/pages/misc/typed.html.haml
index 22274bd..08d53a0 100644
--- a/app/views/pages/soml/typed.html.haml
+++ b/app/views/pages/misc/typed.html.haml
@@ -1,4 +1,4 @@
-= render "pages/soml/menu"
+= render "pages/misc/menu"
%h1= title "Typed intermediate representation"
diff --git a/app/views/pages/rubyx/_menu.haml b/app/views/pages/rubyx/_menu.haml
index a8ec0d1..acc4a63 100644
--- a/app/views/pages/rubyx/_menu.haml
+++ b/app/views/pages/rubyx/_menu.haml
@@ -4,5 +4,3 @@
%li= link_to "Parfait", "parfait.html"
%li= link_to "Debugger", "debugger.html"
%li= link_to "Memory" , "memory.html"
- %li= link_to "Threads" , "threads.html"
- %li= link_to "Optimisation ideas" , "optimisations.html"
diff --git a/app/views/pages/rubyx/optimisations.html.haml b/app/views/pages/rubyx/optimisations.html.haml
deleted file mode 100644
index 8e38bab..0000000
--- a/app/views/pages/rubyx/optimisations.html.haml
+++ /dev/null
@@ -1,75 +0,0 @@
-= render "pages/rubyx/menu"
-
-%h1=title "Optimisation ideas"
-
-%p I won’t manage to implement all of these idea in the beginning, so i just jot them down.
-%h3#avoid-dynamic-lookup Avoid dynamic lookup
-%p This off course is a broad topic, which may be seen under the topic of caching. Slightly wrongly though in my view, as avoiding them is really the aim. Especially for variables.
-%h4#i---instance-variables I - Instance Variables
-%p Ruby has dynamic instance variables, meaning you can add a new one at any time. This is as it should be.
-%p
- But this can easily lead to a dictionary/hash type of implementation. As variable “lookup” is probably
- %em the
- most
- common thing an OO system does, that leads to bad performance (unneccessarily).
-%p
- So instead we keep variables layed out c++ style, continous, array style, at the address of the object. Then we have
- to manage that in a dynamic manner. This (as i mentioned
- = succeed ")" do
- %a{:href => "memory.html"} here
-%p
- When a new variable is added, we create a
- %em new
- Type and change the Type of the object. We can do this as the Type will
- determine the Class of the object, which stays the same. The memory page mentions how this works with constant sized objects.
-%p So, Problem one fixed: instance variable access at O(1)
-%h4#ii---method-lookup II - Method lookup
-%p Off course that helps with Method access. All Methods are at the end variables on some (class) object. But as we can’t very well have the same (continuous) index for a given method name on all classes, it has to be looked up. Or does it?
-%p
- Well, yes it does, but maybe not more than once: We can conceivably store the result, except off course not in a dynamic
- structure as that would defeat the purpose.
-%p
- In fact there could be several caching strategies, possibly for different use cases, possibly determined by actual run-time
- measurements, but for now I just destribe a simeple one using Data-Blocks, Plocks.
-%p
- So at a call-site, we know the name of the function we want to call, and the object we want to call it on, and so have to
- find the actual function object, and by that the actual call address. In abstract terms we want to create a switch with
- 3 cases and a default.
-%p
- So the code is something like, if first cache hit, call first cache , .. times three and if not do the dynamic lookup.
- The Plock can store those cache hits inside the code. So then we “just” need to get the cache loaded.
-%p Initializing the cached values is by normal lazy initialization. Ie we check for nil and if so we do the dynamic lookup, and store the result.
-%p
- Remember, we cache Type against function address. Since Types never change, we’re done. We could (as hinted above)
- do things with counters or robins, but that is for later.
-%p
- Alas: While Types are constant, darn the ruby, method implementations can actually change! And while it is tempting to
- just create a new Type for that too, that would mean going through existing objects and changing the Type, nischt gut.
- So we need change notifications, so when we cache, we must register a change listener and update the generated function,
- or at least nullify it.
-%h3#inlining Inlining
-%p
- Ok, this may not need too much explanation. Just work. It may be intersting to experiment how much this saves, and how much
- inlining is useful. I could imagine at some point it’s the register shuffling that determines the effort, not the
- actual call.
-%p Again the key is the update notifications when some of the inlined functions have changed.
-%p
- And it is important to code the functions so that they have a single exit point, otherwise it gets messy. Up to now this
- was quite simple, but then blocks and exceptions are undone.
-%h3#register-negotiation Register negotiation
-%p
- This is a little less baked, but it comes from the same idea as inlining. As calling functions is a lot of register
- shuffling, we could try to avoid some of that.
-%p More precisely, usually calling conventions have registers in which arguments are passed. And to call an “unknown”, ie any function, some kind of convention is neccessary.
-%p
- But on “cached” functions, where the function is know, it is possible to do something else. And since we have the source
- (ast) of the function around, we can do things previouly imposible.
-%p One such thing may be to recompile the function to acccept arguments exactly where they are in the calling function. Well, now that it’s written down. it does sound a lot like inlining, except without the inlining:-)
-%p
- An expansion if this idea would be to have a Negotiator on every function call. Meaning that the calling function would not
- do any shuffling, but instead call a Negotiator, and the Negotiator does the shuffling and calling of the function.
- This only really makes sense if the register shuffling information is encoded in the Negotiator object (and does not have
- to be passed).
-%p
- Negotiators could do some counting and do the recompiling when it seems worth it. The Negotiator would remove itself from
- the chain and connect called and new receiver directly. How much is in this i couldn’t say though.
diff --git a/app/views/pages/soml/_menu.html.haml b/app/views/pages/soml/_menu.html.haml
deleted file mode 100644
index 967d42b..0000000
--- a/app/views/pages/soml/_menu.html.haml
+++ /dev/null
@@ -1,8 +0,0 @@
-.row
- %ul.nav
- %li
- %a{:href => "typed.html"} Typed
- %li
- %a{:href => "benchmarks.html"} Performance
- %li
- %a{:href => "syntax.html"} Syntax (obsolete)