Submitted by BareMetal is an open source 64-bit OS for x86-64 based computers. It is written in Assembly, and applications can be written in Assembly or C/C++. It’s aimed at three target segments (High Performance Computing, Embedded Applications, and Education). It’s also designed to be simple, and it’s really small. Under 16Kb small. Version 0.4.8 was released recently, which includes updates to the C application library, updated documentation, and better support for SMP. It’s good to see some innovation in the startup/hobbyist OS space. We wish them well!
I don’t think ‘innovative’ is the right word; that implies new and different, even at the expense of clarity or simplicity. This seems to be more basic and clean, the bare minimum bread and butter an OS needs. Not that it’s a knock against the system; simplicity is good.
Poking around their SVN tree, it seems they’re missing a few core functions. Well, I’ve been meaning to poke around with x86-64 assembly anyways…
Edited 2010-07-14 22:07 UTC
Agree. Nothing innovative about this. Just another underpowered hobby project with no useful goals. Not to say that writing an OS or similar project isn’t fun, but it certainly isn’t newsworthy.
Wow, mods don’t like the truth.
Apparently “truth” does not mean what you think it means…
You may be missing the point. It might not be newsworthy on Jon Q. Public’s Random Tech Blog, but this is OSNews. This is what we come here for.
I don’t think it’s even newsworthy here.
I do. I can’t remember the last time I saw news about a 64bit assembly-based OS.
Don’t you mean MOVe around?
(drumroll and apologies).
Welcome home again, OSnews!
This kind of news are what we, your readers, were waiting for
I know, these news are rare these days but I am happy that these research, hobby, alternative OSes still have a place (this place) where they can be introduced and divulged.
I think Osnews is dead, I haven’t seen much of anything of late. Really I come here out of habit and always leave feeling disappointed. Phoronix always has something new and exciting, I just wish OSnews could do the same. I guess though this is just a hobby website and it doesn’t make any money.
I think Osnews is dead,
Hmm, I personally like OSNews. I’ve been a daily visitor for who knows how long now and I can’t say I am disappointed in any way really. One thing I especially like about OSNews is that commenting really works well and there’s often interesting discussions here whereas f.ex. Slashdot’s comments area tends to be full of useless stuff and flamebaits.
But well, each to their own, I s’pose.
If you really come here out of habit you’d know why news has been slow the past month: Thom Holwerda is on a sabbatical for school. David Adams is doing a great job in his absence but as most of the daily news came straight from Thom, there has naturally been a visible effect.
Personally I like the pace of things here now; it reminds me of the old days when Eugenia was at the helm. And, as much as I enjoy Thom’s articles and sense of humor, it’s been refreshing to see all the different points of view in recent submissions.
I have no problems with OSnews posting non-OS articles once in a while. I for one would rather read about interesting non-OS stuff than the latest boring release candidate from SUSE or Ubunthu.
I have found OSnews fair and balanced and intelligent while everyone else are selling their souls way too cheap for ad impressions and vendor cash (Eldar and the Engadget crew, I am looking at you).
So whether its about OS or something else, OSnews does a very good job and I am satisfied.
Edited 2010-07-15 18:40 UTC
Assembly for x86 may have a stable target, but it just isn’t where that kind of tightness is needed. Use the assembly language for LLVM and you can target the architectures in mobile devices – or if you are on a desktop, more readily offload onto the GPU or other resources. Still, who cares? Sounds like these guys are having fun.
It’s under 2 KB? That is compact, like under 8-bit operating system compact.
The Kernel binary (which includes the kernel itself, the CLI, as well as all of the system calls) is 16KiB. In reality it is actually much smaller as the binary is padded out to 16KiB. The compiled binary without padding is 10576 bytes as of 0.4.8
– Ian Seyler @ Return Infinity
Edited 2010-07-15 17:23 UTC
Reminds me of the days of the Atari ST (1986 and later), when the entire OS fit into 192Kbytes of ROM.
If you were to do a 64-bit BareMetal OS version of the Atari ST TOS/GEM, I wonder if you could STILL do it in that amount of space (or less)! I think it might well be VERY possible… and it would be on a 64-bit computer!
You think the Atari ST was fast for it’s day? This type of system would blister the surface of the sun, it’d be so fast! 😀
Good reading about fitting a complete OS, including GUI, in such a small amount of ROM :
http://www.dadhacker.com/blog/?p=995
http://www.dadhacker.com/blog/?p=1000
Kochise
Thanks for the links. I’m not halfway through the first one yet but I’m loving it.
That’s 8 times bigger than what was written in the article, but I guess typographical errors have to scream to be heard.
I hereby give you permission to increase the OS size UP TO 1 MB. Anything above that and we will have to take a vote.
Finally! Some OS NEWS! I wish them good luck in their endeavours. And it’s interesting to see some people still building OSes using assembly (Compact).
Edited 2010-07-15 05:04 UTC
So I guess this wouldn’t be for any generic HPC clusters, but for when you have a specific application that you have the ability to either port or write from scratch, then.
Would be interesting to hear about implementations later on when they get a little more hw support (like network).
Wonder if MPI and InfiniBand and such things are on the map for the future?
It is always nice to see a new kid on the block. They are doing another menuetOS (http://www.menuetos.net/) hope they have at least the same success
We still have a ways to go but we are getting to something that I think has a lot of promise.
Network support is currently the major thing that is lacking. We plan to have some limited support in v0.5.0 (most likely targeting the Realtek 8139 chipset or similar). BareMetal OS nodes will communicate via raw Ethernet frames. Once network access is complete we can use a real cluster of BareMetal OS machines.
Work on the C library needs to be done as well. Currently it is using custom calls for basic operations but we would like to include all of the ANSI C standard functions (printf, scanf, fopen, etc..).
Maybe in the future BareMetal OS could replace Linux on Pixar’s Renderfarm
Thanks,
– Ian Seyler @ Return Infinity
Hi, that’s an interesting goal! To run RenderMan, it’s mostly C bindings, and the shader language is all in software (REYES algo). That should eliminate huge parts of a full POSIX API. Plus, you wouldn’t need proprietary HW drivers, right? You would definitely need networking working for the bytestreams. How are you handling the FS? Just hiding it behind the networking layer? I suppose you could, since the bytestream is god in RenderMan.
Very interesting goal. Good luck! What about more normal MPI/OpenMP type stuff?
Or replace the now dead SkyOS
Get enough of C that Emacs can be ported to it.
Then any computer since the intro of AMD64 can run a very capable OS. It’ll be far huger than the OS (probably take about 16mb, as there’d be no graphics support and a number of other functions stripped), but who cares?
I realise this is no small task, but it’s a worthy task, I think.
Emacs is a very capable OS, if you think back to the days when computing was younger, and look at what it can do now. People just expect an OS to do so much more than what makes an OS. The core of Emacs adds a scripting language with regex, text processing, (if available) rudimentary graphics(which are being improved), tiling window management, rudimentary multitasking(you can run multiple processes, but one waits for the next to finish anything it’s doing, like an old Mac)…
Seriously, with this and Emacs, I’d be at home. Integrate the compiler/debugger with it and you’ve got a full development environment.
It’s a Herculean task, but it’s not as insane as one might think. the C portion’s relatively small, and once the lisp interpreter/byte-compiler are available, the rest is just not including features that BareMetal doesn’t support(yet).
Right, emacs actually got anti-aliasing recently:
http://psung.blogspot.com/2008/03/emacs-in-ubuntu-hardy-now-has-ant…
At this pace, it’s prone to become sentient soon.
Heh. It’s not very advanced when compared to the systems in which it runs (at least in the flashy parts), it is a pretty impressive achievement when you compare it to DOS or a BASIC prompt.
Catching stars with the feet on the ground!!!
That’s the way you can make the world turn.
Congratulations!
Edited 2010-07-15 19:53 UTC
please don’t bother with the ansi C functions such as printf and the rest of that stuff. keep the fresh new calls and make this a modern project not burdened by the ancient crap.
i think a great feature would be to make this project based on UTF-32/UCS-4 unicode.
good luck and thanks for sharing this wonderful work.
What are you saying man?
ANSI C functions are the base of everything… everything ends doing a “malloc”, a “free” or a “memmov”…
Because you live in the virtual machine on top of virtual machines era, creating a lot of garbage that needs to be garbage collected, living in a world full of framework and classes, it does not mean that all the “ancient crap” is still feeding such virtual world.
of course u need to have calls to allocate and free memory or do string manipulation but it can be implemented in a different way other than the old runtime-library way. for example, i have written countless programs for WinNT using the native ntdll.dll API for all these functions and i can tell u that it makes a whole lot more sense than the runtime-library. another example is qnx.
C!=RTL
all i am saying is that being bound by these rules such as runtime-library being a must will render your OS a replica of the old ones.
even the names of the RTL functions make zero sense.
good luck with your efforts.
I like OSNews too… No complaints from me.
On topic… Any chance of an Obj-C runtime?
We haven’t tested C++ or Objective-C yet, but I see no reason why it wouldn’t work. For compiling C applications we support GCC and LLVM/Clang.
– Ian Seyler @ Return Infinity
Why on earth would one need to support objc on a system like this?
C, C++ and a minimal scripting environment (elua?) would seem to make more sense.
Objective C makes at least as much sense as C++.
A possible reason to support objc would be to write (or port) applications in Objective C. That’s all the need you need.
There just isn’t any objective c code worth porting, whereas there is a ton of worthwhile c++ code around.
I beg to differ.
So you know of some portworthy softare written in objc? Is this gnustep or some iFart application?
I know from personal experience (SPARC v9) that assembly programming can be cool, but it has severe limitations:
1. Not suitable for large and complex programs. Every hobby project starts small, so coding everything in assembly may seem like a good idea, but in several years time when the codebase grows and you start adding many more features, it will become difficult to make big changes/additions.
2. Not portable. You wouldn’t be able to port it to a different architecture. I know x86 architecture has lived for many years, but sooner or later it will be superseded by something else. Even advances in the same architecture 32-bit x86 to 64-bit x86 require big changes to assembly code.
I’m pretty sure you all know these things, I just don’t understand why commit everything to one specific architecture. Operating systems can grow to be very complex and the hardware changes/evolves pretty quickly.
It is their project, so they can do whatever they want. If the goal is embedded or high performance applications, it makes sense to make the OS as simple and bare as possible.
Furthermore any of those “insights” you related are common wisdom items which can be derived without having written a single line of assembly code. Also, if you have programmed in assembly you should know that a lot of code such as interrupt servicing is very architecture-specific so it is not really that portable (regardless of whether you write it in a high level language or not). So writing an OS in C, for example, does not make it automatically portable.
Lastly, betting on X86-64 is a very safe bet, as we can make a clear case that such architecture, unlike SPARC, is not going away anytime soon.
BareMetal OS will always be lean and mean. Allowing it to get “large and complex” would defeat our goals. The OS provides just the basics (keyboard input, screen output, disk (and eventually Ethernet) access). BareMetal OS will never replace the OS on your desktop/notebook because that is not what it is being designed for. We want something that gets out of the way when an application is running.
As for portability we don’t think the x86 architecture will be replaced any time soon. Also the great thing about x86 is that it is everywhere. While high-level compilers do a good job at compiling code we prefer being in full control of what opcodes the CPU is executing (and in what order). Does GCC or LLVM/Clang optimize for “branchless” code if it can?
– Ian Seyler @ Return Infinity
And good to see you going for the x86-64 cpu generation. Those extra registers must sure be handy.
Heh, I can certainly understand the preference of ‘full control’ since it’s also part of my own nature. That said, compiler optimization has matured alot these past years and although they will never offer the same level of control (and likely not the same level of optimization as that of an assembly guru) I personally find it ‘close enough’ for the majority of cases. Newer optimization techniques like PGO (profile guided optimization) offers you branch prediction, efficient instruction cache usage, function reordering, loop unrolling etc in an automated way. Again, a great assembly programmer can beat this I’m sure, but it will require a great level of skill and more time. Please don’t think I’m putting your efforts down, I admire your willingness and skill to write an os in pure assembly and having programmed alot in x86 assembly during my time I find it very inspirational. Today, most of the places I see assembly code is in BIOS’es, really low level OS stuff and special optimizations such as video encoding/decoding. Seeing it applied on a whole OS project is very impressive.
Yes, GCC will transform conditional jumps into branchless equivalents wherever applicable, and I’m certain the same is true for LLVM although I’m too lazy to look it up (hey, it’s summer).
But at least multi-threading should be added. Or did I oversee it in the sources ?
Actually, IMHO, something that calls itself an OS today needs to support multitasking and or multi-threading.
Anyway, good to see there are more freaks around doing pure assembly 🙂
Multi-threading is supported but not in the way that other Operating Systems use it.
BareMetal OS uses a Process Queue. An application can throw as many “work loads” as it wants into the Process Queue and any available CPU Cores will begin to work on them.
There is a presentation on the topic here:
http://vimeo.com/13423853“>BareMetal
Good luck controlling the order instructions are executed in… how many years has it been since out-of-order execution was introduced to CPUs?
(yeah, I’m nit-picking).
out-of-order execution is no problem for assembler programming. Why should it be ? There are always synchronization points like return from subroutine or memory barriers. Only if you need to be sure some code has been executed before another is started, you have to insert such sync-point by yourself.
I could see this or other low footprint OS’s used for specialty applications deployed on VM’s. Use many VM’s, each one with a different application.
That’s a project someone needs to take up. Lately, I’ve been wondering why I need the rest of the junk when I only what to run BIND in a VM.
This really is a step in the right direction for HPC. The overhead of memory management doesn’t really make sense for a node that is dedicated to one application. If it dies, the job manager can just reset the node!
I’m wondering if it will be a problem that applications have full control. they can push a lot of pakages to the network, which could be damaging for the rest of the system.
A solution might be to use LLVM byte code, or similar, for applications. Then verify that they only use the network through a controlled interface. The job manager could do this and perform the final compilation.
I like OSNews because they talk about applications and generally everything that affects an OS, be it local or remote.
BareMetal + WINE = ???
The site suggests BareMetal targets HPC, embedded systems, and education. To that list I suggest adding secure systems.
Too bloated.