OSNews

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).

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

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! :-D

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.

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.

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?

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.

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.