Jekyll2019-12-12T01:13:50+01:00/feed.xmlViua VM weeklyA blog covering recent developments in Viua VM and related projects. Posts published every Tuesday.
New docs2019-12-12T00:10:00+01:002019-12-12T00:10:00+01:00/issue/issue-35<p>
No technical stuff in this post. Just a heads-up that new documentation is
being written.
</p>
<hr>
<section>
<h1 id="new-docs">New docs</h1>
<p>
There is a new documentation available that describes all public
instructions and register sets. The
<a href="https://docs.viuavm.org/isa">ISA docs</a> are not yet finished
but <em>all</em> instructions have their syntax forms documented so you
can experiment with them and see what they are doing.
</p>
</section>No technical stuff in this post. Just a heads-up that new documentation is being written.Slow, but (almost) steady2019-09-01T02:57:00+02:002019-09-01T02:57:00+02:00/issue/issue-34<p>
No technical information in this post. It's mostly an update on the general
state of things in the Viua VM-land.
</p>
<hr>
<section>
<h1 id="still-alive">Still alive</h1>
<p>
Viua VM is not dead. The rumours about its demise were greatly
exaggerated. In fact, it is the best shape it ever was and has
seen usage in almost-real-world projects (I was dogfooding during my
engineer's degree final project).
</p>
<p>
However, the development substantially slowed down in recent times.
There's no denying that the amount of code I put out there is in no way
comparable to what it used to be. This is particularly due to the amount
of work I had to do in the academia (a degree does not earn itself) and
industry (the bills do not want to pay themselves). This are just lazy
excuses, though.
</p>
<p>
Hopefully, the pace of progress should now pick up a little as I have a
bit more free time on my hands. If it doesn't - too bad, but the VM is
definitely not dead.
</p>
</section>
<section>
<h1 id="io-schedulers-and-instructions">I/O schedulers and instructions</h1>
<p>
One of the most recent additions were I/O schedulers and I/O
instructions. In theory, they should take some load off of FFI
schedulers which were until now used to execute both CPU-related and
I/O-related calls.
</p>
<p>
I/O is based on ports, requests, and interactions.
First you open an I/O port (it can represent a file, a socket, a pipe,
etc.). Then, you use this port to submit I/O requests to the kernel and
then to I/O schedulers.
User code sees the I/O operation to perform as an "I/O request"
value, the kernel sees it as an "I/O interaction" to perform - they
are both linked together by an ID assigned to every I/O interaction.
</p>
<p>
While an I/O scheduler goes about executing an I/O interaction the user
code may wait for an I/O request to become complete (either successfully
or with an error) or cancel it. I/O is performed asynchronously (after
an I/O interaction is submitted the user code just receives a handle, in
the form of an I/O request value) and the user code is not blocked.
It must explicitly block on an I/O request by using the
<code>io_wait</code> instruction.
Alternatively, if the request does not complete for too long it may be
cancelled using the <code>io_cancel</code> instruction.
</p>
</section>No technical information in this post. It's mostly an update on the general state of things in the Viua VM-land.More documentation2018-02-06T18:01:34+01:002018-02-06T18:01:34+01:00/issue/issue-33<p>
Once again, not much happened except for new documentation being written.
</p>
<hr>
<section>
<h1 id="more-documentation">More documentation</h1>
<p>
Documentation has been expanded to include chapters about the general architecture
of the VM, as seen by the programmer.
The documentation is available <a href="https://docs.viuavm.org/manual.html">here</a>.
</p>
</section>Once again, not much happened except for new documentation being written.Documentation continues2018-01-30T18:44:17+01:002018-01-30T18:44:17+01:00/issue/issue-32<p>
Once again, not much happened except for new documentation being written.
</p>
<hr>
<section>
<h1 id="documentation-effort-continues">Documentation effort continues</h1>
<p>
Documentation for Viua VM has been expanded by quite a few new chapters in the last week.
The document has also been renamed to "Viua VM manual".
</p>
<p>
Among the new instructions that were documented are
<a href="https://docs.viuavm.org/manual.html#6-25"><code>process</code></a>,
<a href="https://docs.viuavm.org/manual.html#6-18"><code>join</code></a> (both for concurrency),
<a href="https://docs.viuavm.org/manual.html#6-10"><code>function</code></a> (create a function ref),
<a href="https://docs.viuavm.org/manual.html#6-3"><code>call</code></a>,
<a href="https://docs.viuavm.org/manual.html#6-23"><code>pamv</code></a> (pass a parameter by move),
<a href="https://docs.viuavm.org/manual.html#6-24"><code>param</code></a> (pass a parameter by copy),
<a href="https://docs.viuavm.org/manual.html#6-27"><code>return</code></a>,
<a href="https://docs.viuavm.org/manual.html#6-8"><code>frame</code></a> (construct a call frame),
<a href="https://docs.viuavm.org/manual.html#6-2"><code>arg</code></a> (obtain passed argument),
and
<a href="https://docs.viuavm.org/manual.html#6-13"><code>import</code></a>.
</p>
<p>
The manual is now in an overall better shape as more references are now being used in text;
especially the HTML version is now much more usable as the refs allow the reader to jump from
one interesting section to the next.
</p>
<h2>Future content</h2>
<p>
The manual now also includes two sections that are just stubs to be be expanded in the future, but
are tremendously important - the environment (that the VM provides), and the standard library.
</p>
<p>
The first one will describe the environment in which the programs running on Viua VM are executed;
this includes program organisation, description of available error handling techniques, how
concurrency is realised in the VM, etc.
</p>
<p>
The second will describe the standard library supplied with the VM (which so far is of poor
quality, and extremely limited usefulness).
</p>
</section>
<section>
<h1 id="pdf-version">PDF version</h1>
<p>
A <a href="https://docs.viuavm.org/manual.pdf">PDF version</a> has been made available to
accompany the HTML and plaintext versions.
</p>
</section>Once again, not much happened except for new documentation being written.More documentation2018-01-23T21:38:04+01:002018-01-23T21:38:04+01:00/issue/issue-31<p>
Once again, not much happened except for new documentation being written.
</p>
<hr>
<section>
<h1 id="more-documentation">More documentation</h1>
<p>
Assembly language <a href="https://docs.viuavm.org/manual.html#3-1">directives</a> and
<a href="https://docs.viuavm.org/manual.html#3-2-1">function definitions</a>
are now partially documented.
</p>
</section>Once again, not much happened except for new documentation being written.More documentation2018-01-16T18:15:06+01:002018-01-16T18:15:06+01:00/issue/issue-30<p>
Last week was spent only on writing documentation.
No new code was introduced to the codebase of the VM.
The work will most likely resume after most currently available features are documented.
</p>
<hr>
<section>
<h1 id="documentation-for-tools">Documentation for tools</h1>
<p>
Basic documentation is now available for
<a href="https://docs.viuavm.org/manual.html#4-1">assembler</a>,
<a href="https://docs.viuavm.org/manual.html#4-2">kernel</a>,
and <a href="https://docs.viuavm.org/manual.html#4-3">assembler</a>.
</p>
<h3>Assembler</h3>
<p>
Features of the assembler (type checking, static control-flow and register access analysis, type
inference) are now shortly described.
Also, it is noted that the assembler also performs the role of the linker.
</p>
<h3>Kernel</h3>
<p>
Kernel <a href="https://docs.viuavm.org/manual.html#4-2-1">environment variables</a> are described.
These variables may be used to tune some aspects of the kernel, or enable execution traces which are
useful for debugging your programs (or the VM).
</p>
<h3>Disassembler</h3>
<p>
A brief description is provided, along with the list of its deficiencies.
Disassembler is probably the least-frequently used tool of the three, so these deficiencies are not
high on the list of priorities (for now, at least).
</p>
</section>Last week was spent only on writing documentation. No new code was introduced to the codebase of the VM. The work will most likely resume after most currently available features are documented.New documentation2018-01-09T18:50:22+01:002018-01-09T18:50:22+01:00/issue/issue-29<p>
New documentation is being written.
So far it does not cover all instructions and is not as in-depth as it should be, but it is only a matter
of time before it will be.
</p>
<hr>
<section>
<h1 id="new-documentation">New documentation</h1>
<p>
New documentation is written in a form of a single-file document covering
<strong><em>everything</em></strong> there is to cover about the VM.
Available instructions, syntax of the assembly language, tools that are shipped in a standard
distribution, programming techniques, etc.
</p>
<p>
There are three versions of the manual (all with the same content):
</p>
<ul>
<li> <a href="https://docs.viuavm.org/manual.txt">plaintext</a> version </a> </li>
<li> <a href="https://docs.viuavm.org/manual.html">colorised HTML</a> version (dark background, light
text) </a> </li>
<li> <a href="https://docs.viuavm.org/manual.nocolor.html">browser-default HTML</a> version (whatever
your browser-default colors happen to be </a> </li>
</ul>
<p>
All versions have <em>exactly</em> the same content, and are rendered in <em>exactly</em> the same
way; except for the colors and links from ToC to sections in the HTML versions.
</p>
</section>New documentation is being written. So far it does not cover all instructions and is not as in-depth as it should be, but it is only a matter of time before it will be.Document all the things!2018-01-02T18:35:33+01:002018-01-02T18:35:33+01:00/issue/issue-28<p>
</p>
<hr>
<section>
<h1 id="a-new-take-on-documentation">A new take on documentation</h1>
<p>
Another attempt at documenting user-visible Viua interface is being made.
There are several things that require attention, and which <em>have to</em> be documented.
In no particular order:
</p>
<ul>
<li> the instruction set </li>
<li> what is a register? </li>
<li> what is a <em>register set</em>? </li>
<li> how to access values held in registers? </li>
<li> what is the execution model of the VM (asynchronously communicating processes)? </li>
<li> how to send and receive messages? </li>
<li> how to handle errors? </li>
<li> how to do I/O? </li>
</ul>
<p>
These are all important issues, but Viua does not currently provide documentation for them in any
form.
There are several articles in a few places, almost 600 example programs written for Viua, but this is
not enough for the VM to be usable.
</p>
<p>
The newest place when documentation can be found is <a href="https://docs.viuavm.org/manual.txt">here</a>.
It combines documentation of available instructions with explanations of the core concepts of Viua VM:
registers, register sets, value lifetimes, types, processes, messages, exceptions and error handling.
</p>
</section>
<section>
<h1 id="finished-exception-handling-wiring-rework">Finished exception-handling wiring rework</h1>
<p>
Explicit <code>new</code>s were removed from Viua code, removing the last place where naked pointers
to dynamically allocated objects were used and increasing the overall reliability of Viua VM.
</p>
</section>Wiring improvements2017-12-19T17:12:09+01:002017-12-19T17:12:09+01:00/issue/issue-27<p>
Last week was spent on implementation of subtraction instructions, and
on improving machine's internals.
</p>
<hr>
<section>
<h1 id="signed-subtraction">Signed subtraction</h1>
<p>
It turned out that dedicated subtraction instructions are needed after all.
</p>
<p>
For wrapping arithmetic a separate subtraction instruction is not as critical as for the other types
of arithmetic.
There subtraction is just the regular "flip the bits, add one" and add.
However, for checked or saturating arithmetic additional checks must be done and that justifies adding
additional opcodes to the VM's instruction set:
<code>checkedssub</code> (checked signed subtraction),
<code>checkedusub</code> (checked unsigned subtraction),
<code>saturatingssub</code> (saturating signed subtraction),
<code>saturatingusub</code> (saturating unsigned subtraction), and
<code>wrapsub</code> (wrapping subtraction).
</p>
<p>
For now, only the signed versions were implemented.
Unsigned versions will be implemented with the rest of unsigned arithmetic instructions.
</p>
</section>
<section>
<h1 id="improved-memory-safety-during-exception-handling">Improved memory safety during exception handling</h1>
<p>
Exception handling is the last part of Viua where one can see naked "<code>new</code>" and
"<code>delete</code>".
During this week a rework operation has been started to move to <code>std::unique_ptr</code> for all
exception handling.
Lifetimes of all values inside Viua (that are visible to the user code, as exceptions are) are managed
through <code>std::unique_ptr</code>s, and exceptions were the last holdouts not abiding by this rule.
This will change during the following week.
</p>
</section>Last week was spent on implementation of subtraction instructions, and on improving machine's internals.Signed fixed-width arithmetic implementation is complete2017-12-12T19:21:32+01:002017-12-12T19:21:32+01:00/issue/issue-26<p>
Last two weeks were <em>slow</em>.
Not much happened.
Mostly small improvements, and some work around the VM (CI maintenance, checking compiler behaviour, etc.).
</p>
<hr>
<section>
<h1 id="saturating-signed-division">Saturating signed division</h1>
<p>
Saturating signed division instruction <code>saturatingsdiv</code> was implemented.
This was the last instruction to be implemented for signed values, which means that the signed
fixed-width arithmetic implementation is now (mostly) complete.
</p>
</section>
<section>
<h1 id="fixed-width-arithmetic-in-devel-branch">Fixed width arithmetic in devel branch</h1>
<p>
Signed fixed-width arithmetic instructions
<a href="http://git.savannah.nongnu.org/cgit/viuavm.git/commit/?h=devel&id=c9c46309c70e6bc2f8ac8b96d970ebd6f47959cd"><code>were merged</code></a>
into <a href="http://git.savannah.nongnu.org/cgit/viuavm.git/log/?h=devel"><code>devel</code> branch</a>.
</p>
</section>
<section>
<h1 id="preparations-for-better-type-checker">Preparations for better type checker</h1>
<p>
Current type checker for Viua VM assembly is incredibly limited, and is unable to check more complex
types.
This comes mostly from the limitations of the type inferencer.
"Complex type" means that the type is parametrised by more than one value (or the parametrisation goes
more than one level deep).
</p>
<p>
As an example: the inferencer is able to correctly and fully deduce a type "pointer to
<code>T</code>", but is unable to deduce "vector of pointer to <code>T</code>" and will leave such
values as "vector of pointer to value" which means that anything goes.
The final goal for the inferencer and checker is to be able to deduce arbitratily nested types, e.g.
"pointer to vector of vector of pointer to text" (in C++ this would be
"<code>std::vector<std::vector<std::string*>>*</code>".
Type checker could then use the detailed types to better verify programs.
</p>
<p>
What is more, the static analyser could employ the richer type information provided by the enhanced
inferencer to check things other than types:
<strong>1/</strong> process joinability,
<strong>2/</strong> bit shifts and operations (i.e. ensuring that matching widths are used, or that
no narrowing conversions happen),
<strong>3/</strong> whether fixed width arithmetic operations are used consistently,
etc.
</p>
<p>
There are no plans, though, to extend the support to verify types of fields in structures.
The type checker and static analyser will only ensure that the types are used consistently, but Viua
VM assembly will not provide a way to declare types for structure fields (similarly as it does not
provide a way to declare types of functions - they are only verified for consistency of use, not
declared explicitly).
This functionality will be left for higher-level languages.
</p>
</section>Last two weeks were slow. Not much happened. Mostly small improvements, and some work around the VM (CI maintenance, checking compiler behaviour, etc.).