Tuesday, December 28, 2010

After my recent bug fixes, HelenOS is able to serve a web page from inside Qemu. TCP is still shaky, sometimes it works, sometimes it does not. But it's still progress :-). In the past weeks and months I got my hands dirty in the networking stack and I tell you, the code is weird throughout!

The web server is mostly fake, but it does serve its purpose :-) I should be committing it shortly.

Immediately after placing my order I set upon a quest. A quest to construct my own computing device. An so, after more than three months of planning, designing, etching, drilling and soldering I proudly present to you (lots of drum rolls and dramatic chords..) the one, the only, Fanatik 1!

I should get back to you soon with more details on the F-1. I will also present you with a series of quizzes. Today the question is simple: Try to name as many Speccy computer game protagonists as you can recognize etched on the Fanatik board. The winner will receive an original browser cookie.

Monday, October 25, 2010

Many of you already know I've been busy with a 'top secret' electronics project. Especially Jakub has been nagging me to reveal something. Today I can share with you this photo of some mysterious tests that I've been performing. The results were satisfactory. That's all I will say for now. Mwahahaha!

For those less versed in electronics let me describe the action for you. What you see in the picture are three joined-up breadboards. On the breadboards we see some DIL ICs plus a bunch of wires and other stuff. The thing on the middle breadboard is a surface-mounted IC soldered to a home-made PCB which has pins on the bottom side and allows one to plug the chip into the breadboard.

And yes, the thing on the left side is a Logitronik II because George says every mad scientist should have a Logitronik II in their basement.

Monday, August 9, 2010

The guys from the (presumably dead) TUNES project seem to have liked writing essays more than actually writing code. (At least I was not able to find any). Compared to their cloud-castle project, Sysel seems boring and pure mainstream ^_^.

While cannot agree with everything therein, the article (or manifesto or whatever it is) accurately points out the principal weaknesses of microkernel design as such (as well as the faults in existing microkernel-based designs).

Thursday, July 29, 2010

The magical Pandora's box surely worked its magic on me. I am now on the waiting list for the Pandora Console having just pre-ordered (and pre-payed) it. Now I just have to bear with the incredibly looong waiting time. (Supposing I do receive the console, it will be a pleasant surprise if I receive it this calendar year. Surprise me.)

When I bought the Neo FreeRunner it was mostly for the sake of porting HelenOS to it as I am not really into smartphones. It is still a cool device, though, thanks to the integrated Wireless Ethernet, GPS and accelerometers (and the openness, of course).

With Pandora the situation is a little different. I really like old games and this is the retro gaming device. The real selling point for me is the keyboard (although it probably is not a great one). Pandora also has gamepad controls, but I don't really like gamepads, anyway. It also has integrated WiFi (just imagine the multiplayer possibilities!) So I definitely want to use it on gaming (you could call it love at first sight).

Porting HelenOS to Pandora should be relatively easy now, I should think, as I've already fixed the bugs that prevented HelenOS from running on a real ARM processor (despite working in emulators). Also, Pandora uses U-Boot just as FreeRunner does, so bootloader should not be a problem either.

Anyway it will be long before I have my Pandora, so I still have plenty of time to improve FreeRunner support :-)

The surrounding discussion is is pretty much the old battle between C++ proponents (who point out its many merits) and opponents (who point out its many flaws). Concerns about speed and the need to teach GCC devs to use C++. Concerns about 'misuse of C++ features.' I find the slowness argument especially amusing since Clang/LLVM is written in C++ and it does not appear to be suffer from severe performance problems.

And of course there are those who suggest only to use a subset of C++ that would not incur performance penalty nor contain features that are 'easily misused'. I hear many software projects claiming to use C++ are actually written in different, mutually incompatible subsets of C++ (using or not using exceptions, RTTI, templates, etc.) This seems to be encouraged by the historically bad conformance of C++ compilers to the language standard.

Looking away from the rather amusing bickering, does this change affect me, a mere mortal user? Well normally I couldn't care less. When I compile GCC on Linux this certainly does not present any problem. From HelenOS point of view, this is more interesting.

To make HelenOS self-hosting, we need to be able to have some compiler which can be compiled within the system. Question is, which compiler should it be? Today GCC is still a hot candidate -- it is probably the only compiler supporting all the CPU architectures and other features we need. Another selling point was it being written in C -- which it will now lose. In the future it would be necessary to implement or port the C++ standard library (and STL) to HelenOS in order to compile GCC in it.

This makes GCC drop closer to Clang/LLVM on our suitability ladder. (Clang/LLVM is also written in C++). Practically the only remaining deficiency of Clang/LLVM w.r.t GCC is that unlike LLVM itself, which should have good support for several architectures, Clang currently only has good support for i386/x86_64. It should not be hard to improve Clang support for other targets, but still there must be sufficient demand to drive the development (Apple does not need it).

Another player in the field is the Portable C Compiler. It is written in C, but it is a relatively small project and supports only a few CPU architectures. (Interestingly neither LLVM nor PCC support Intel Itanium architecture). I have some misgivings against depending on such project whose future is not very certain.

In any case, the choice of a (first) C compiler to run in HelenOS remains open for now.

Friday, March 5, 2010

I am pleased to say that SBI (Sysel Bootstrap Interpreter) is making good progress. You can already create object instances, play with the variadic built-in function Exec, raise and handle exceptions, etc.

Now I know you might think I am just being silly, but I still haven't decided on how to write comments. Basically I am oscillating between hash (as you saw in previous posts) and dash (--), i.e. double hyphen, for denoting comments.

Hash is easier for me to type, because I can type hash with my left hand and use arrow keys with my right hand at the same time. For double hyphen I either need to use the little finger of my right hand, or lift the hand and move it towards the minus key.

From aesthetic point of view... I just don't know. Most of the time I seem to prefer dash, although it clashes with the bullet point hyphens in the BSD license in the HelenOS format (but an alternative form could be used for that).

What I am quite confident with is that the commonly used comments should be single-line comments, where comments blocks would be created by typing in a series of single-line comments. Multi-line comments would only be used for disabling sections of code (typically for debugging purposes).

Doc-blocks will be started by a special single-line comment (such as ## or ---) and continued by regular single-line comments (such as # or --).

An interesting idea here pertains to the way of denoting the 'brief' part of the doc block. The common methods include: (1) up to the first period (.), (2) the first paragraph, (3) the first paragraph if marked with some special tag (such as @brief). Another way which came to my mind is that if the 'brief' part spanned more than one line, all these lines would use the same doc-comment mark. Example:

## First line of doc brief and## this is the second line.# # This is no longer part of# the brief.

or

--- First line of doc brief and--- this is the second line.- - This is no longer part of- the brief.

Do you like one of these comment styles better than the other? If so, why? Or would you recommend yet another one? Let's hear ye!

Tuesday, February 23, 2010

It is alive! I had to put in some hacks to avoid name conflicts and I had to implement fgets() in the HelenOS C library, but SBI now works in HelenOS. It's not really a big deal, as SBI still doesn't do so much, but it's still nice.

Monday, February 22, 2010

I guess I cannot pretend it's a secret anymore. I am working on Sysel. What is sysel? Well, sysel is the Czech name for the European ground squirrel, or, in layman's terms, the European gopher.

Sysel with capital S is a programming language, however. From the previous posts you should already have some idea how Sysel should look like. Right now (in the 'first phase') I am developing Sysel Bootstrap Interpreter (or SBI for short). This is an interpreter of Sysel written in C.

The main purpose of SBI is to bootstrap the prospective self-hosting Sysel compiler, as well as serving as a testbed and refining the language design. Nevertheless, SBI will run under both POSIX-based systems and, of course, HelenOS. SBI as well as other Sysel tools that I will produce will be available under the same BSD-like license that is used by HelenOS.

Only real geeks develop alternative operating systems. Therefore, hopefully, by creating an alternative programming language to develop an alternative operating system in, I will be able to achieve whole new levels of geekiness.

I have created a project on Launchpad where you can now track my progress. I will also publish a HelenOS+SBI branch when that's ready.

I'll give you a few options. This C# program, when compiled with GMCS will:

(a) Compile without error and print "Hello World!" five times. (b) Compile without error, but abort with a runtime error. (c) Abort compilation because of the cyclic inheritance. (d) Abort compilation because A.B is not defined. (e) Abort compilation because A.B.B is not defined. (f) Crash the compiler.

Wednesday, February 3, 2010

I started to play around with the Mono C# compiler. Since all my previous experience with C# has been just passive (i.e. reading tutorials), I started with something very simple: a class implementing a generic doubly linked list. (It's completely brain dead, but should be sufficient for this example.)

I thought it would be fun to convert it to an alternative syntax, so here it is. Note for example the syntax for type parameters. I also added some more specific ideas, like translatable strings with annotations, Python-like for loop, or the with-except-finally statement. The snippet is rather long, which is good, as it should deliver a more authentic experience. For the most part, this a transcription of real C# code, while some of it is completely constructed. If you don't know C# please be careful not to credit me with its inventions.

What I like about this syntactic style is that it avoid C#'s sort of 'German' word order. Public static override void ... wait, where was I? Here, the name of the object being declared is reasonably close to the beginning (just the second word). Also the first word let's us know what kind of object we are dealing with (function, variable, class, etc.).

My fingers didn't really object. Even though 'end' has three characters while '}' has one, short keywords are actually easier to write than special symbols which require Shift to type. My eyes were O.K with it, too -- each declaration is visibly anchored and appears to be balanced. So I am reasonably happy with this creation.

What about you? Do you like it?

## Generic list type.## Really just an example of program syntax style. This list can be# appended to or prepended. It implements an enumerator and an# indexer. Backwards or random-direction iteration is not possible.## This class has one generic parameter (t), implements the# IEnumerable interface. t is subject to the constraint t : class# (t is a reference type) and the class MyList't is public.## Note that this is meant only to demonstrate syntax style and# it's almost 1-1 translation of a C# program. (But some special# syntactic ideas are also demonstrated.#class MyList't : IEnumerable, where t : class, public is

i = 0; e = head.next; while true do if e == head then raise new Exception(); end if i == pos then break; end i += 1; e = e.next; end

return e; end

## Number of nodes in the list. # # Property - looks like a member variable, but assigning # to it or reading from it can have side effects. # prop length : int, public is get is return getLength(); end end

## Indexer # # This a simpler variant of [] operator overloading. Here # we can define the effects of reading from / writing to # an object of this class with index (e.g. list[3]). # prop this[pos : int], public is get is return getNodeAt(pos).data; end set is getNodeAt(pos).data = value; end end

## An example how a variadic function might be declared (var# attribute). The + means that the argument must not be null.# The whole piece of code is disabled using a multi-line 'comment'# block. Only single-line comments are meant to be used for comments# per se, while multi-line blocks are meant for disabling sections# of code quickly.#

# It's really better always to iterate over some # list. We don't need a C-style for(;;) so no need # to call this foreach. for o : string in list do Console.writeLine("Node " + o); end

# Instead of for (i = 0; i < 10; ++i) for i : int in range(0, 9) do Console.writeLine(i); end

# # It would be possible to combine a context- # management statement with a try block. So, # try/except/finally can be thought of as a special # case where we do not need to guard any resources # with the 'with' statement. # with f : TextFile = TextFile.OpenFile("test.txt") do # If any exception happens here, f is cleaned up # gracefully via f.dispose() (or similar) var line : string = f.readLine(); Console.writeLine(line); except e : Exception do # And likely we also want to handle the exception Console.writeLine("Error reading file."); finally Console.writeLine("Done"); end endend

Wednesday, January 20, 2010

In search of inspiration for language syntax style I remembered Lua. It takes the third major path apart from curly braces (C) and off-side rule (Python). It is thus reminiscent of the Algol family, especially Ada, UNIX shell syntax or Karel (at least some incarnations thereof).

Lua is (mostly) free-form and uses what I call in my head (inappropriately, perhaps) implicit block delimiters. Where a declaration of some program element in C might look like

declaration { element; element; ...}

in Lua it is instead

declaration element; element; ...end

What I like about the latter case is that programmer is freed of the choice whether or not to use curly braces to delimit a single statement in control flow expressions such as if, for, while. Still, the language remains free-form and the code looks visually balanced to my eyes. For some reason I feel the cosmic balance disturbed if the beginning end end statement are not both marked, with the same indentation. In Python the blocks feel– incomplete– without the final delimiter. Of course, which style has better signal-to-noise ratio, can be disputed.

Here, Lua is somewhat more concise than Ada or Fortran where we annotate what kind of block we are ending (e.g. if ... then ... else ... end if) in hope of helping the programmer match the delimiters more easily (and to help the compiler spot bracketing errors).

One design element of Lua syntax that I don't really like is the freedom to or not to terminate any statement with a semicolon. Instead a statement can be terminated with a newline. On one hand this allows us to avoid using punctuation unless necessary, on the other hand the language is not fully free-form. Quoting from the reference manual, the code

a = f(g).x(a)

would be mistaken for two statements. Gorgeous ^_^.

In Ada all statements (and other program elements) are terminated with a semicolon. The Prosody IM software written in Lua seems to have adopted a coding style where every simple statement is terminated with a semicolon, while any compound statement or element ending with the end keyword is not.

Conclusion: While Lua syntax style need not be perfect, it demonstrates that even this syntactic style does not have to be excessively verbose. I like it enough to consider its style as a primary source of inspiration.

Monday, January 4, 2010

Anyway, I can hardly imagine a supercalifragilisticexpialidocious operating system such as HelenOS can be 0.70710678118654757 as supercalifragilisticexpialidocious if it is written in C. Rather than using an existing programming language which is not s32s enough, I'd much rather design my own programming language.

There are two cons: (1) bigger adoption barrier, (2) designing a language and writing the compiler is not a small job. (As a starting point for an estimate, the C compiler I wrote a few years ago while I was still at Uni took me (very roughly) 300 hours before it could compile itself. In this case I would have to design the language and write two compilers. The first compiler (or interpreter) would have to be written in an existing language to bootstrap the new language and the other one a native compiler (i.e. written in the language itself).

I have some idea of the main semantic features the language should have. The most important difference from C#, the basic integer type should allow for arbitrary-size numbers, as in Python. That's one important step Microsoft did not take.

I am still looking for a good inspiration for the syntax though. I'd rather not go into curly braces. I like a lot of ideas from Python's syntax a lot. However, in a statically typed language the lines can get longer and this might not work as well. I also consider taking inspiration from functional languages such as Haskell for function-call syntax (i.e. 'f x y' instead of 'f(x, y)') although this might not work well with passing keyword arguments (passing arguments with names explicitly specified).

In case you are wondering, yes, I already have designed a completely useless programming language (and wrote a compiler for it) and not published it. So I definitely do know I am perfectly capable of just that. Again.

There you have it, I spent the whole evening babbling. However, if the sum of time other people spend reading these posts exceeds the time I spend writing them, then vengeance will be mine! Maybe next time I will cover some less revolutionary, boring and virtual topic. Or not.

If I wanted to make this article look interesting, I would title it C considered harmful, but I will not. HelenOS is written in C. C is a programming language created at the beginning of 1970's. It's creation is closely tied with the birth of UNIX. At the time of its creation, C was a simple and yet extremely powerful programming language.

C maps (or can map) rather closely to the hardware. Originally it required no or very little run-time support. (What this means: a piece of code using only the core language -- not library routines -- can be compiled directly to machine code and does not require additional libraries or other support to execute).

For quite some time C has been showing its age. Both the core language and the standard library are becoming more and more inadequate for implementation of applications.

Working with strings has always been an extreme pain in C, but with multi-byte encoding (i.e. UCS/Unicode) it has become a nightmare. In HelenOS we decided to drop the standard C99 way of handling multi-byte strings altogether and implement our own. Needles to say, it's only a little better, the language won't allow us more. I demand automatic memory management! I demand user-defined operators!

String formatting in C is a chapter on its own. While this could be re-implemented in the standard library to be extensible (i.e. allow the consumer to register a formatting function for their custom type) we cannot really do away with the need to provide the type of argument in the formatting string, at least not in a sensible way. I demand virtual methods!

What usually drives me mad is the complexity involved in using a hash table in HelenOS. I need to implement several callbacks just to get my int->pointer map. I want generics! I demand collections!

There is a plan to implement a graphical user interface for HelenOS. Having to implement it in C is just giving me the Willies. We would probably end up with some monstrosity like GTK... or worse. I demand inheritance!

Now wait a minute... this blog has existed for a few months already, but the first post is dated today?! That can mean only two things: either (a) I am the laziest person in the solar system or (b) I prefer coding to writing about coding.

This blog shall deal mostly with my contributions and ideas for HelenOS. If you don't know what HelenOS is by the time you've finished reading this sentence, then you obviously have not followed the hyperlink embedded within it. Redo from start. Now you know HelenOS is a supercalifragilisticexpialidocious operating system.

This information is mostly targeted at fellow HelenOS developers and enthusiasts so I will probably not bother to explain all background for the average passer-by most of the time.

I might also blog here about other geeky stuff not related or vaguely related to HelenOS. That is, if I manage to blog at all. Because of (a) or (b).

Hey Jakub, I blogged! Jakub's been persuading me to blog about HelenOS for some time. So there. I've blogged. Blogo ergo sum. Although I don't have a MySpace account. So I don't exist. And I don't have FaceBook account nor a Twitter account nor a Peprnet acount and omega other accounts. So the cardinality of my non-existence set is omega. Doh.