58 lines
2.8 KiB
Plaintext
58 lines
2.8 KiB
Plaintext
|
%p
|
|||
|
|
Quite long ago i
|
|||
|
|
%a{:href => "/2014/06/27/an-exceptional-thought.html"} had already determined
|
|||
|
|
that return
|
|||
|
|
addresses and exceptional return addresses should be explicitly stored in the message.
|
|||
|
|
%p
|
|||
|
|
It was also clear that Message would have to be a linked list. Just managing that list at run-time
|
|||
|
|
in Register Instructions (ie almost assembly) proved hard. Not that i was creating Message objects
|
|||
|
|
but i did shuffle their links about. I linked and unlinked messages by setting their next/prev fields
|
|||
|
|
at runtime.
|
|||
|
|
%h2#the-list-is-static The List is static
|
|||
|
|
%p
|
|||
|
|
Now i realized that touching the list structure in any way at runtime is not necessary.
|
|||
|
|
The list is completely static, ie created at compile time and never changed.
|
|||
|
|
%p
|
|||
|
|
To be more precise: I created the Messages at compile time and set them up as a forward linked list.
|
|||
|
|
Each Item had
|
|||
|
|
%em caller
|
|||
|
|
field (a backlink) which i then filled at run-time. I was keeping the next
|
|||
|
|
message to be used as a variable in the Space, and because that is basically global it was
|
|||
|
|
relatively easy to update when making a call.
|
|||
|
|
But i noticed when debugging that when i updated the message’s next field, it was already set to
|
|||
|
|
the value i was setting it to. And that made me stumble and think. Off course!
|
|||
|
|
%p
|
|||
|
|
It is the data
|
|||
|
|
%strong in
|
|||
|
|
the Messages that changes. But not the Message, nor the call chain.
|
|||
|
|
%p
|
|||
|
|
As programmer one has the call graph in mind and as that is a graph, i was thinking that the
|
|||
|
|
Message list changes. But no. When working on one message, it is always the same message one sends
|
|||
|
|
next. Just as one always returns to the same one that called.
|
|||
|
|
%p It is the addresses and Method arguments that change, not the message.
|
|||
|
|
%p
|
|||
|
|
The best analogy i can think of is when calling a friend. Whatever you say, it is alwas the same
|
|||
|
|
number you call.
|
|||
|
|
%p
|
|||
|
|
Or in C terms, when using the stack (push/pop), it is not the stack memory that changes, only the
|
|||
|
|
pointer to the top. A stack is an array, right, so the array stays the same,
|
|||
|
|
even it’s size stays the same. Only the used part of it changes.
|
|||
|
|
%h2#simplifies-call-model Simplifies call model
|
|||
|
|
%p
|
|||
|
|
Obviously this simplifies the way one thinks about calls. Just stick the data into the pre-existing
|
|||
|
|
Message objects and go.
|
|||
|
|
%p
|
|||
|
|
When i first had the
|
|||
|
|
%a{:href => "/2014/06/27/an-exceptional-thought.html"} return address as argument
|
|||
|
|
idea,
|
|||
|
|
i was thinking that in case of exception one would have to garbage collect Messages.
|
|||
|
|
In the same way that i was thinking that they need to be dynamically managed.
|
|||
|
|
%p
|
|||
|
|
Wrong again. The message chain (double linked list to be precise) stays. One just needs to clear
|
|||
|
|
the data out from them, so that garbage does get collected. Anyway, it’s all quite simple and that’s
|
|||
|
|
nice.
|
|||
|
|
%p
|
|||
|
|
As an upshot from this new simplicity we get
|
|||
|
|
= succeed "." do
|
|||
|
|
%strong speed
|