OSDev.org

The competition is now open! Cash prized paid via paypal for the most bugs and bugfixes as detailed below: USD$ 70, 50 and 30 for first, second and third place respectively. Please help me to make this product worthy of being released.

In other news, horizon is now in the LLVM2.8 release notes

Thanks, and happy hacking!

Hello all,

I've been rather inactive for the past few months, so for those who don't know me I'm a moderator here and have been around for quite a while.

Over the past year (since leaving the Pedigree development team) I've been working on a project of my own - initially helped by froggey and AlexExtreme - this project has its first release scheduled for December 1st.

The project is called "Horizon", and is a bytecode compiler built atop LLVM. It compiles a safe, efficient bytecode to LLVM bitcode which is then compiled to machine code. This is done both ahead-of-time and just-in-time - I have set up a faux-posix environment which provides just enough functionality for LLVM, libstdc++ and boost to run on bare metal.

The bytecode is designed to allow hobbyist OS developers easy access to the new and exciting area of single-address-space OS development, pioneered by Inferno but brought to our attention by project such as Singularity, JNode and Cosmos.

More information can be found on the project wiki page, which also contains links to the user-facing and developer-facing Doxygen documentation.

Horizon aims to sacrifice some of the safety aspects of Java and C# (which Cosmos and JNode are based on), such as exception handling, to be faster. In fact, the tests in my master's thesis on Horizon showed Horizon as being faster than the equivalent C code for Dhrystone (the compiler was able to reason better about Horizon's bitcode and optimise away the main loop). This is obviously only one benchmark and a poor one at that, but at the time Horizon could only run integer operations, which reduced the number of benchmarks I could run!

How does this affect me? Where's this money?

I want to release a quality product. I have a suite of regression tests, but I'm only one person. I can't find all the bugs I might want to. So I'm making a competition in which hopefully I might enlist some of your help, and you might get some compensation in return.

I will be offering three prizes: $70, $50 and $30. These are USD obviously, and the conversion rate will be whatever PayPal decides to give me on the day from the equivalent in GBP.

The competition will run for 4 weeks from October 1st, subject to a full set of rules which will be published, and will consist of a points system.

* You get one point for successfully finding a bug (the definition of which will be set in the rules - i.e. it must not be a duplicate and must cause a segfault or an assert to fire), documenting it and adding it to the tracker.
* You get three points for successfully fixing a bug, including providing a regression test and patch.

You don't have to have found a bug in order to fix it - i.e. you can poach others' bug reports!

The prizes will be awarded to first, second and third place when ranked by number of points over the competition period. Ties will be arbited by adding prizes up and splitting them equally.

I'll put the rules up more towards the time, but I'd like to know if people are actually interested - it would be a massive help to me, and I'd much appreciate any help you could give, even if you couldn't care less about the money!

What do I need to compile Horizon?

A linux box. That's it. You don't need a crosscompiler, your native g++ will do. Oh, and it won't work with cygwin, due to the way the baremetal stuff is written (it emulates linux).

Project website is at http://www.quokforge.org/projects/horizon
Any questions to [email protected] , or
IRC on freenode.net, #horizonos .

Cheers!

James

Ever since hearing about singularity ive thought that llvm was more suited to that concept. I am very interested in contributing to a project like this. Prize money is just icing on the cake!

It checks out fine now, however seeing as it is only supported on 64bit systems I will not be participating come the 1st . Good luck, perhaps I will check this out again in the future.

Alas! I'm only supporting 64-bit targets, and as for this OS the host == target, it can only be built on 64-bit systems. Sorry about that! maybe use a 64-bit VM? or is your chipset still 32-bit?

Thanks for looking into it, anyway!

James

Hi Genious, Keep it up, I m also very interested to know more about it. But i can not help, becz i am also using 32-bit chip........

Any way i will try to know more about that.....

best of luck.............

As a followup, the competition will be going ahead from this monday, the 4th October, and will run for 4 weeks.

Another post on Sunday.

Thanks for the interest those who replied; I'd really appreciate anyone's help, no matter how small!

James

Bump, competition now open. See the edit in the top post.

Bugs count as internal faults, incorrect LLVM code generated, obvious other bugs.

Bugs that include compiler FIXMEs or TODOs are valid too, as I want them documented.

Duplicate bugs are not counted, and whether a bug is valid or not is up to myself only (I'm not going to try and steal points from you - it's just so that anyone gaming the system can be stopped).

Cheers!

James

Noone entered, which is bad for my product but good for my wallet!

So what's the latest status, given we're a half year futher?


JAL

Like Solar quoted

I started a new job, I haven't had much time to work on Horizon. When I left it, the bytecode compiler was fully functional, with a full language description and documentation. The high-level-language I was building along with it was at the AST->bytecode compilation stage, with tests still being written.

Horizon is pretty well tested.

My current project is a fork of that, applying some of the techniques I used with horizon to Python in an attempt to reach a larger audience.

EDIT: Current status of that:



Still a way to go!

I have a question about that: a while ago (a year probably? time flies) there was a discussion on this forum on using bytecode for developing platform agnostic hardware drivers, and iirc LLVM was rejected because its bytecode lacked some features needed to be used for that. Did you run into anything like that?

Ah, yes, this was the post I had in mind.

JAL

Short answer? No.

Longer answer? LLVM is extremely portable, however with C and C-like languages the IR is not expressive enough to cover some of the more technical features, for example:

* Proper union support
* Typedefs and enumerations
* Alignment information

The last is the most important - Clang and llvm-gcc both convert pretty much all structs into byte-arrays and back again to deal with alignment.

The IR that these frontends generate is not portable because it already has things like sizeof(void*) and native alignments baked in.

This doesn't mean that the IR itself isn't portable - it just isn't for C-like languages. I didn't run into this because my bytecode isn't C-like and lacks some of the more "unique" features to C, such as variable alignment and structure packing (the frontend relies on LLVM to pack and align appropriately instead of baking in explicit information).

Is this still active?
Competition?
Are there final times?

Please read dead threads before reviving them. This is from October 2010