ruby-x/ruby-x.github.io
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

minor

Browse Source
This commit is contained in:
Torsten Ruger 2015-11-23 14:18:44 +02:00
parent eb8099db31
commit f999a3aefb
2 changed files with 35 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
2014-07-28-active-objects.md
View File

@ -3,69 +3,70 @@ layout: site
author: Torsten
---
Part of what got me started on this project was the intuition that our programming model is in some way broken and so by
good old programmers logic: you haven't understood it til you programmed it, I started to walk into the fog.
Part of what got me started on this project was the intuition that our programming model is in some way broken and so by
good old programmers logic: you haven't understood it till you programmed it, I started to walk into the fog.
### FPGA's
Don't ask me why they should be called Field Programmable Gate Arrays, but they have facinated me for years, because off
course they offer the "ultimate" in programming. Do away with fixed cpu instruction sets and get the programm in silicon.
Yeah!
Don't ask me why they should be called Field Programmable Gate Arrays, but they have fascinated me for years,
because off course they offer the "ultimate" in programming. Do away with fixed cpu instruction sets and get the program in silicon. Yeah!
But several attempts at learning the black magic have left me only little the wiser. Verlilog or VHDL are the languages that
make up 80-90% of what is used and they so not object oriented, or in any way user friendly. So that has been on the long
list, until i bumped into [pshdl](http://pshdl.org/) by way of Karstens [excellent video on it](https://www.youtube.com/watch?v=Er9luiBa32k). Pshdl aim to be simple and indeed looks it. Also similuation is exact
and fast. Definately the way to go Karsten!
But several attempts at learning the black magic have left me only little the wiser.
Verlilog or VHDL are the languages that make up 80-90% of what is used and they so not object oriented,
or in any way user friendly. So that has been on the long
list, until i bumped into [pshdl](http://pshdl.org/) by way of Karstens [excellent video on it](https://www.youtube.com/watch?v=Er9luiBa32k). Pshdl aim to be simple and indeed looks it. Also simulation is exact
and fast. Definitely the way to go Karsten!
But what struck me is something he said. That in hardware programming it's all about getting your design/programm to fit into
the space you have, and make the timing of the gates work.
And i realized that is what is missing from our programming model: time and space. There is no time, as calls happen
And i realized that is what is missing from our programming model: time and space. There is no time, as calls happen
sequentially / always immediately. And there is no space as we have global memory with random access, unlimited by virtual
memory. But the world we live in is governed by time and space, and that governs the way our brain works.
### Active Objects vs threads
That is off course not soo new, and the actir model has been created to fix that. And while i haven't used it much,
That is off course not soo new, and the actor model has been created to fix that. And while i haven't used it much,
i believe it does, especially in non techie problems. And [Celluloid](http://celluloid.io/) seems to be a great
implementation of that idea.
Off course Celluloid needs native threads, so you'll need to run rubinius or jruby. Understandibly. And so we have
Off course Celluloid needs native threads, so you'll need to run rubinius or jruby. Understandibly. And so we have
a fix for the problem, if we use celluloid.
But it is a fix, it is not part of the system. The system has sequetial calls per thread and threads. Threads are evil as
i explain (rant about?) [here](/salama/threads.html), mainly because of the shared global memory.
i explain (rant about?) [here](/salama/threads.html), mainly because of the shared global memory.
### Messaging with inboxes
If you read the rant (it is a little older) you'll se that it established the problem (shared global memory) but does not
propose a solution as such. The solution came from a combination of the rant,
If you read the rant (it is a little older) you'll se that it established the problem (shared global memory) but does not propose a solution as such. The solution came from a combination of the rant,
the [previous post](/2014/07/17/framing.html) and the fpga physical perspective.
A physical view would be that we have a fixed number of object places on the chip (like a cache) and as the previous post
explains, sending is creating a message (yet another object) and transferring control. Now in a physical view control is
not in one place like in a cpu. Any gate can switch at any cycle, so any object could be "active" at every cycle (without
going into any detail about what that means).
A physical view would be that we have a fixed number of object places on the chip (like a cache) and
as the previous post explains, sending is creating a message (yet another object) and transferring
control. Now in a physical view control is not in one place like in a cpu. Any gate can switch at
any cycle, so any object could be "active" at every cycle (without going into any detail about what that means).
But it got me thinking how that would be coordinated, because one object doing two things may lead to trouble. But one of
the Sythesis ideas was [lock free synchronisation](http://valerieaurora.org/synthesis/SynthesisOS/ch5.html)
But it got me thinking how that would be coordinated, because one object doing two things may lead
to trouble. But one of the Sythesis ideas was [lock free synchronisation](http://valerieaurora.org/synthesis/SynthesisOS/ch5.html)
by use of a test-and-swap primitive.
So if every object had an inbox, in a similar way that each object has a class now, we could create the message and put it
there. And by default we would expect it to be empty, and test that and if so put our message there. Otherwise we queue it.
So if every object had an inbox, in a similar way that each object has a class now, we could create
the message and put it there. And by default we would expect it to be empty, and test that and if
so put our message there. Otherwise we queue it.
From a sender perspective the process is: create a new Message, fill it with data, put it to receivers inbox. From a
receivers perspective it's check you inbox, if empty do nothing, otherwise do what it says. Do what it says could easily
include the ruby rules for finding methods. Ie check if your youself have a method by that name, send to super if not etc.
From a sender perspective the process is: create a new Message, fill it with data, put it to
receivers inbox. From a receivers perspective it's check you inbox, if empty do nothing,
otherwise do what it says. Do what it says could easily include the ruby rules for finding methods.
Ie check if your yourself have a method by that name, send to super if not etc.
In a fpga setting this would be even nicer, as all lookups could be implemented by associative memory and thus happen in one
cycle. Though there would be some manager needed to manage which objects are on the chip and which could be hoisted off.
Nothing more complicated than a virtual memory manager though.
In a fpga setting this would be even nicer, as all lookups could be implemented by associative memory
and thus happen in one cycle. Though there would be some manager needed to manage which objects are
on the chip and which could be hoisted off. Nothing more complicated than a virtual memory manager though.
The inbox idea represents a solution to the thread problem and has the added benefit of being easy to understand and
The inbox idea represents a solution to the thread problem and has the added benefit of being easy to understand and
possibly even to implement. It should also make it safe to run several kernel threads, though i prefer the idea of
only having one or two kernel threads that do exclusively system calls and the rest with green threads that use
only having one or two kernel threads that do exclusively system calls and the rest with green threads that use
home grown scheduling.
This approach also makes one way messaging very natural though one would have to inent a syntax for that. And futures should
come easy too.
This approach also makes one way messaging very natural though one would have to invent a syntax for
that. And futures should come easy too.

2
_layouts/salama.html
View File

@ -10,7 +10,7 @@ layout: site
</div>
</div>
<div class="span2">
<h2 class="center">More Detail</h2>
<h3 class="center">More Detail</h2>
<div>
<ul class="nav nav-list">
<li><a href="/salama/layers.html"> Layers of Salama </a> </li>