180 amps!!!! Im sure he meant watts :)

Now that is interesting, they developed something that is not only amazingo but a great learning tool

I suppose this makes sense to me for embedded system applications that require a fair bit of high-precision math – I’m thinking video processing. So maybe useful for a rover or something.

Still, I’m a bit confused as hardware’s fairly cheap. I guess if I were building something to leave the planet, I’d be interested in this kind of thing.

@haybales – You’d see a lot more bugs. When was the last time you saw a compiler bug cause an application to crash? Or even a kernel to Oops?

Also, debugging assembly (machine code) isn’t the same as running your friendly debugger on a corefile. I dont know what tools they provide, but the reason for higher level languages is to make this bug-find-and-fix problem a little easier to live with.

They promote it for HPC usage? What the HPC area doesn’t need is yet another platform that will be unmaintained in 20 years time. There is a reason why the HPC world have OpenMP and MPI. HPC programs tend to live forever if they are doing something useful.

I agree with IceBrain, despite the fact that actually any OS contains pieces of assembly, this is just pointless for computation because the overhead is minimal.

Classic assembly OSs like MULTICS and the Burroughs MCP (of TRON fame) had huge advantages in that they were written on CPUs designed with multitasking, multiple users and networking in mind.

What people need to realize is that decades ago a MULTICS machines could be physically taken apart while users were logged in, moved part by part to another location and reassembled – all without the users knowing.

The popular modern systems are driven by economic utility to the sellers (proprietary lock in) not technical merit or good engineering principles.

A 16k OS? Sweet! Should turn some heads in the field!

The value of simple assembly code is inversely proportional to the length of your CPU pipeline. The longer your pipeline, the more it hurts to handle branches the ‘simple’ way.

Say you have a piece of code that checks a bit and executes routine A on a 1, routine B on a 0, then returns and does some other math with the results. Following that path directly is fine if the CPU completely executes one instruction before starting the next, but practically no CPU does that any more.. they break the execution process into stages, and execute them in parallel.

The classic RISC pipeline is 5 stages long: fetch the next instruction, decode it, execute it, do memory I/O, then do register I/O. If we have to wait for the conditional to decide what the next instruction will be, it means there will be at least four empty slots in the pipeline. The first instruction of routine A or B won’t happen until at least 4 clock cycles after the conditional.

Microcontrollers like the AVR and PIC have short pipelines — only 2 stages — so that doesn’t hurt too much.

The IA-64 architecture, OTOH, has a 10-stage pipeline. It also has 30 execution units divided into 11 different groups, and its fetch mechanism can feed 2 instructions into the pipeline per cycle. The challenge is to keep them all working efficiently at once.

For that architecture, it would be more efficient to load both routine A *and* routine B into the pipeline before the conditional even finishes executing. That way, at least the one you need will be ready to go by the time you decide which branch to take. The CPU will just drop the branch that wasn’t chosen, but that doesn’t cost any more than letting those units sit idle while you waited for the conditional. It would also be more efficient to pipeline any code that follows the call to A/B that can be executed independently of A/B, or which can treat the result of A/B as a value in register R.

Point is, compilers don’t produce convoluted assembly code because the back-end programmers were dumb, and ‘simple’ isn’t necessarily a virtue when you have multiple paths of parallel execution.

Just thought i’d mention that you can write your applications in c/c++, you are not limited to assembly. Just because the os and libs are written in assembly doesn’t mean that you are limited to assembly.

I have it fired up in qemu, and it is a pretty fun toy.

First up, this project is brilliant (I like it), but the comments here have been really out-there. Writing a whole OS in assembler is fun and a useful thing to do as a learning tool, but for people arguing “oh but it’s faster!” for production use: I remain unconvinced that any speed advantages aren’t far outweighed by problems; portability (see next point), maintainability, etc.

The people wanting to run this on their PSP/ARM board/Car ECU are both hitting the nail on the head — good luck, x86-only and realistically cannot be ported without a total rewrite — and sh1t out of luck.

The people arguing that old mainframes had OSes written in assembler are ignoring the reasons: saving every byte was crucial when you had 2MB of memory and it cost you $2M, and old compilers were awful.

Anyone wetting themselves about the newfound possibilities of your x86 machine running this — ZOMG I can calculate X now, I couldn’t before! — probably doesn’t realise how little overhead running, say, Linux has. You will not suddenly get a 50% performance boost by not running an OS written in C. You will not suddenly get “more precise calculations”; you’ll find your FP is exactly as accurate as it used to be and if you find you now can do 64bit integer stuff on your x86-64, you were running the wrong 32bit-only kernel before.

Yes, GCC et al aren’t perfect. If you’re really concerned about your algorithm’s speed, write the core algo (and no more, go read Knuth) in assembler in userland AND hack on GCC to improve it. This is not the same as writing your OS in assembler. If your OS and compiler really do add lots of overhead, *fix them*, as they shouldn’t.

HPC is more than just performance; OSes like Linux have necessary things like clustered filesystems, varied I/O (anyone want to write a FC/Infiniband driver for this asm OS?), and god forbid, compilers. Even FORTRAN. ;-)

Rant almost over: Some of the memory footprint comments are both exaggerated and not as much of an issue as you make out. I don’t see HPC vendors desperate to reduce their kernel footprint from a few tens (yes) of MB to a few tens of KB. There are comments about your OS wasting cycles on managing devices, etc. Are you suggesting your OS polls all of your devices just for fun? If your OS is spending cycles managing your disc controller it is because, and only because, there is something disc-related that needs to be done! Whether your OS is baremetal or not, your data isn’t going to come off disc without you asking for it. The percentage of time “wasted” by this code being written in C is tiny, and the percentage of time your processor spends doing this is tiny, resulting in tiny^2 time wastage having a C driver doing this. I would much prefer my SATA driver/precious filesystem runs 0.1% slower if it’s less buggy!

Wait, not quite over: In many HPC scenarios your application code (be it hand-written assembler, C or FORTRAN, depending on how much of a pervert you are) is running on your CPUs 100% of the time; your I/O will often be separated on different nodes to the computational nodes. Before someone complains about a 100Hz tick interrupt reducing the number of L33t Algorithm Cycles available to play WoW via a neural net, on many systems you may experience NO IRQs unless you want them. (E.g. IRIX has a “switch scheduling tick off” syscall ;-) ) Tickless kernels, huge pages, pinned CPUs, your working set fully RAM-resident; at this point your OS may as well be written in BASIC because it’s having to actually do anything while your application runs :P :) Plus, you won’t have to spend thousands of personyears writing drivers for all the hardware you need to use.

@mstone: It’s easy to handle race conditions like that with clever programming. Without having seen the code for this, I think that is likely one of the things they handled in this OS. It’s a pretty basic consideration in programming for a thread-capable architecture.

Cool project, good learning experience, and somewhat useful.

The problem is who is going to write applications for this, assembler has one hell of a learning curve and most modern programs are written in C/C++.

If they want this thing to be used much, they need to port glibc or newlib to it. I would replace several virtual machines with it if they did. (I am only assuming they haven’t at this point.)

I tried writing my own OS, and it’s a lot of fun and I imagine they do it more for fun than they do for some made up overhead and computational power reasons.

For embedded though this is useless. 64bit x86 processors?! Embedded in what? A space shuttle?

hackaday wrote:
“Any hackaday readers have an idea on how to use an OS stripped down to the ‘bare metal?’”

@hackaday:
you basically answered your own question in the sentence “By writing the OS in assembly, runtime speeds are increased, and there’s very little overhead for when every clock cycle counts.” Any time getting the most out of a piece of hardware is necessary, assembly seems to be the language of choice.

For example, most home video games that came out in the 16-bit era or earlier were written in assembly. There are some pretty impressive games for Genesis and SNES that squeezed every bit of processing power out of the hardware because they were written in Assembly.

Even some software for modern OSes were written in assembly. Remember bleem!, the PS1 emulator? Almost entirely written in assembly. Not perfect, but impressive for the time it was released. It ran on a variety of computers, even those not top-of-the-line (as long as it had a 3D-capable video card).

@hackday

>the inefficient obfuscated machine code
>generated by higher level languages like

Do you have anything to back that statement up.. sure you don’t mean “generates code that is sometimes hard to understand because of all the various things the compiler is considering at compile time.. like pipelines, caches etc”.

>Java.

Do you have a snippet of Java generated asm. And I mean for the host machine not for the VM… A great deal of Java bytecode will never make it to native code..

>>writing the OS in assembly, runtime speeds

Until some tiny coding mistake/misunderstanding causes the pipeline to be evacuated…

You see these sorts of statements all the time. I regularly see “I’m an 68000 expert!!” types moaning about the code GCC generates.. yet they don’t seem to have the balls to bring it up on the GCC lists.. I wonder why that is?

@anti-fanboi

>>ASM execution is ALWAYS faster than

If the code you are writing is very small and simple or specific.. maybe. Maybe if your processor is a z80.

>>Java

Java has a JIT compiler.. for larger projects you will see the code Java is generate get faster and faster as it compiles common code paths down to native code and removes unused code out of the way. Can you do that in assembly without writing your own virtual machine?

>>“Good” code has a poetic nature to it,

You’re a Ruby dev aren’t you?

>>really good code actually reads like poetry

Oh dear.

>>requires virtually no comments

I never want to have to work on any code you have written.

>>If you can’t even think in assembler

Which assembly (I think you’ll find an assembler is actually the program that turns assembly into opcodes..) are you talking about? You seem to be making the point that people that don’t understand assembly aren’t good programmers.. but fail to mention what you are actually talking about. Almost anyone could generate nice assembly code for the z80 or something else of that level complexity.. but I think people that can generate efficient code for modern processors are few and far between and those people should be working on compilers.

>don’t pretend to know.

Is that not what you are doing right now?
/me is confused.

>The “cpu cycles are cheaper than coder salaries”

Its about using the right tool for the job.. sometimes that is asm, most of the time it isn’t. Don’t try to make out it’s some “real coder” vs THE MAN! issue. If your boss/client asks you for an online shop you would be a retard to write it in assembly even if you could. You would also be a retard if you wrote a video encoder in PHP (unless it was for fun).

@cantido: thankx for bringing a reasonable voice in this silly thread

Vi or Emacs ;¬)

>>Assembly/assembler…

Have they? I have always known an assembler to be something thing turns assembly into executable code. I’m going to call source files editors from now on.

>>If you can’t think in a language
>> .. wrong tool for the job?

Most of the popular high level languages are very similar and you should be able to pick them up if you have experience in another. Over time you also learn the “tricks of the trade” that will make you better in that language (if the compiler is clever the output shouldn’t differ greatly). There is no need to be over romantic about it. A lot of the time the language doesn’t matter anyhow, its all about the frameworks you have and the libraries available.
The same is actually true of “assembler”.. if you do some asm in DOS using the services provided by int 21h it can seem like x86 assembly is amazingly easy and your code is magically compact.. in reality controlling everything in assembly by yourself is actually not that much fun and the resulting code can be nasty when you need to do workarounds. This is exactly the point of high level languages and OS services.. to handle crap that is non-trivial, messy and not commonly understood. Kernels like Windows and Linux and their c libraries contain tons of hand crafted asm code by people that “know what they are doing”.. like finely tuned memcpy implementations. Why reinvent the wheel we someone else has done it already, tested it, benchmarked it etc?
If we go a level higher with Java.. most of the stuff your code will be doing is calling into Java’s standard library. Which does contain hand crafted asm where it is needed and when your code is doing something that can be turned into an efficient piece of native code the JIT will do that.. it will even create different versions tuned to the current situation.

In summary “use the right tool for the job”.

>>If you’ve never seen the poetry in any language

I have seen good code, and I have seen clever solutions to problems. Most of the time clever solutions are commented to show why they are A: clever and B: work. Not commenting stuff is just stupid.

>dread Assembler

What “Assembler” are you talking about here? One machine can be very different to another.. hell there are even different assembly syntaxes for the same archs. Lots of people hate x86, 8051 etc asm but love z80 or m68k. Lots of ARM cores have some degree of hardware support for executing Java bytecode…. assembler isn’t a language like C. It’s describes a family of “languages” that are human readable representations of the machine’s programming model.

Understanding some basic CS concepts – Good
Understanding the machine you’re using – Good
If you’re doing something on the metal.. like a bare mental MCU project; Understand enough of the machine to do stuff that isn’t always possible in C etc.. like interrupt setup – Good
Hand tuning code paths after profiling – Good
Doing crazy bit banging shit in what ever asm your machine uses for fun or demo coding – Good

Trying to make out GCC, Java etc are “slower” than “assembler” without benchmarks, real world scenarios, the balls to back it up – Bad
Using “assembler” out of some eliteness romantic “my code is art” bullshit – Bad
Blaming “MBAs” for the fact that you would need to be batshit insane in 2011 to write even tiny embedded applications purely in “assembler” – Bad
Blaming “MBAs” for your code being a messy pile of uncommented poetic crap — Bad

WARNING – the below numbers are just random.
Lets say that an traditional OS has 99% of it’s resources available for crunching and that BareMetal OS allows 99.99% for crunching.

Typical machine 2GB RAM; 2GHz CPU

99% is 20MB of RAM and 20MHz of CPU cycles.
99.99% is 200KB of RAM and 200KHz of CPU cycles.

In a traditional 1000 node cluster this is 10 machines used for the OS overhead, so 990 machines for crunching. With BareMetal OS it would be 0.1 machines lost due to OS overhead.

Advantages
———-
Traditional OS would give you more flexibility, better hardware fault monitoring, better device drivers for multiple hardware configurations. Support for distributed network file systems.

BareMetal OS if implemented correctly could squeeze every last drop of performance from the CPU and RAM.

Disadvantages
————-
Traditional gives a small wasted resource overhead.

BareMetal OS no has current support for partial hardware failure notification, network DFS nor GPU acceleration.

It is not an ideal OS for a large scale HPC installation. I personally think that it is brilliant, just not for HPC.

>Do a quick search on Amazon for “assembler”

Google -> Amazon Assembler

Amazon.com: The Art of Assembly Language (0689145119725)

ARM Assembly: Amazon.co.uk

> /dig Well ..

Meh.

>>you don’t know assembler
>>and you’re making an OS

Ok

>>who are not afraid of the assembler
>>boogie man ;)

So, there are MBAs that are involved in having OSes written, but don’t want any assembly.. how does that work? Also unless your OS is a tiny toy of a thing that is very specific to a certain application/piece of hardware you would only right parts that need to be written in assembly in assembly. So your argument still doesn’t work. Those evil MBAs you don’t like aren’t telling people to write operating systems in Perl or VB, don’t be so paranoid.

>>GCC as a language just to be ironic right? :D

C doesn’t generate bad code.. it doesn’t generate any code. GCC does, you can put LLVM’s C backend or SDCC in there if you want. However people complain a lot about GCC’s code generation.. they disassemble the code and then start saying “oh just look at this mess, GCC is crap, I am awesome” without looking at the bigger picture or any confidence in their “findings” to actually mention it to anyone that might matter. Presumably out of fear that they would get their ass handed to them.

>>takes 100′s of MHz or GHz

Writing stuff in assembly doesn’t magically make bad coders into good coders. You can code really shit code in assembly if you want.. modern machines are A: hellafast, B: designed to run code generated by high level language compilers that know how their pipeline etc work. If we take this OS as an example.. ok so you might save one machines worth of overhead in your cluster from having a bare metal environment.. but the cost of getting everything working sanely might be much more than 10 machines and that will only grow as you try to maintain it.. getting someone to write drivers for your obscure OS isn’t going to be easy or cheap. This is like cladding your house in ONE MILLLION US DOLLARS worth of solar cells and generating $500 dollars of electricity.

Gawd, it’s like explaining biology to a creationist, you really do need comments don’t you… or was that an attempt to be deliberately dishonest?

//
// Convention: comments follow statements.
//

Do a quick search on Amazon for “assembler”

//
// go to http://www.amazon.com in a web browser,
// firefox is a good choice.
// at the top of the page where is says “search”
// from the drop down: select “book”
// in the search text field: type “assembler”
// click on “go” or just hit return on the
// keyboard.
//
// on the first page you will find:
//
// MVS Assembler Language
// by Kevin McQuillen and Anne Prince
//
// Assembler Language Programming for IBM and
// IBM Compatible Computers [Formerly 370/360
// Assembler Language Programming]
// by Nancy Stern, Alden Sager and
// Robert A. Stern
//
// Advanced Assembler Language and MVS
// Interfaces: For IBM Systems and Application
// Programmers
// by Carmine Cannatello
//

You seem to be arguing with yourself now? I’m not bashing GCC so let it go OK. Compilers as a whole do the same thing. Here’s a hint: why is it that there are different levels of optimise and why are they flags and not always “on”?

You also seem to think compilers are written by computing gods or voodoo or something? Ideally that would be the case (the gods not the voodoo) but life aint ideal.

You’re obviously a smart guy so I expect one day you’ll get it, I can only try to show you not force you. I was young once and also knew everything, now I’m old and have better things to do ;)

Cheers.

Holy crap, troll project has brought out the trolls in force…

From an economic point of view, the optimum effort for a widely distributed system and a boutique system are rarely the same. For something that will only run occasionally on a single machine, you might use any number of quick to develop languages. However, for an OS that runs on 100M machines many hours a day for years, saving $100M in development only saves $1 per installed instance and can easily waste more than $1 worth of additional power, RAM & HD overhead over it’s life cycle. This exists on a single coder level too. When coder productivity is measured in lines of code, they tend to gravitate toward Java & C++ where automated generator tools can puke out hundreds of lines a day that compile but do nothing useful. Slightly better coders will refactor already working code over and over adding no utility but introducing the possibility of new bugs. The buyers don’t understand the real cost. This is how big developers end up with bad programmers. This is how big companies end up with bad software.

From a technical standpoint, most of the major theory problems were solved decades ago yet commercial implementors continue to reinvent the wheel badly sometimes though ignorance, sometimes to avoid patents and sometimes to lock in their own systems. For example, it has been proven that separate stacks for data and addresses is dramatically more secure than mixed stacks. That was known before the x86 was developed yet the x86 mixes them. The JVM is software written decades later but it makes the same mistake. It has been proven that 3 stacks can solve all computable processes. Most compilers remap to stacks and then remap to the mixed mess of stacks & registers on popular CPUs. JVM is software only but it copies the same bad x86 hardware design in software. Speculative execution may appear optimal for a single tasking benchmark but Cray figured out decades ago that when you have a branch in a multitasking environment it’s better to switch to unblocked code and continue running full speed while the conditional is resolved on the side. Total performance of the system is greater even though the single thread may be slightly less. It’s also a much simpler solution in hardware than hyperthreading to keeping pipelines full.

The real problem in many cases is not technical but the entrenched economic interests that fight to keep their revenue extraction systems in place. That’s why real innovation usually comes out of small projects.

He was off by one in the number of primes because he skipped the number ’2′. He started his testing a3 and incremented by 2 each time because other than ’2′, all primes are odd.

I remember Bill Basham writing a 7 line chat
program for the Apple //e in assembler.
I still have the program even though it’s going to
be 28 years old this June.
There’s a lot to be said for assembly language.
I may not know the IBM stuff, but for me, there will
always be a special place in my heart for the 6502.

A bit late to this game. http://www.menuetos.net/

BTW it fits on a floppy.

@wardy +1. Extremely cool project, but I just can’t see its real life applications.

The application demonstrated should be written in assembler for performance, but the OS could be written in a high level language and perform nearly as well. This is because there are few system calls and application interruptions required for this application.

I’ve worked on assembler OSs, device drivers and application programs, and am a fan of assembler, in the right circumstance. Like many assembler programmers, I specialize in high performance, well organized programming.

Another aspect of this is that the kind of people that would get the actual benefit of crunching numbers on such a scale are probably not those people capable (or indeed motivated) enough to actually write highly optimised assembly code better than your average optimising C compiler (GCC et al.)

So your average science boffin wanting to simulate some new theoretical technology that produces anti-matter at room temperature from a 9v battery will have to hunt around for at least one speccy ASM nerd intimately familiar with this super-obscure OS. It’s just not going to happen.

There’s a bunch of reasons why most of the top500 clusters use RedHat or ScientificLinux.

I’m glad there’s a couple of people here who know what they’re talking about.

Well seems like this could be used in computing clusters to process huge amounts of raw data such as the data CERN collects with their LHC

Just look at the code, it’s not even close to optimal. A good compiler should generate better code and a good programmer using a good compiler should be able to get about the same memory footprint.

Not trying to troll BTW.

those who can code a 64bit os small enough to fit in 16KB do. Those who cant, troll, complian, whine.

i reckon they could use the OS in some small devices that could mimick a human using a computer – like say in AI laden military gadgets running 64 bit processors and this OS.

but fairly enough, not many people would want to write assembly programs so this would have only rare or custom uses to people who might just see its real use

Assembler is a provoking language.What has all these whiners to loose by what you do.Nothing.What I think is a pitty is that few people has discovered HLA which is an assembler where you can go from high level to low level and faster than C and takes a little bit longer to develop.You can also use all levels in HLA from macro to micro.I also think a lot of good languagages are better for applications than all this overcomplicated mainstream shit like C,Python,Perl,C++,etc.Why not Assembler for basic work like the kernel and use simple to learn languages like Newlisp,Euphoria,Rebol,and possibly others that are efficient and easy to work with for applications.I think what you do is great and don´t give up because of these morons.

I have no idea what algorithm they are using, but I just wrote the following 20 some line brute force program in c++ and compiled WITHOUT optimization in gcc and it still runs in a tenth of a second…On a Pentium 4 :P I just don’t understand why it takes their program so long, especially since it is so “pure”.


#include
#include

int main(int argc, char* argv[])
{
int count = 1;
for ( int i = 3; i <= 300000; ++i )
{
bool prime = true;
int root = 1+(int)(sqrt(i));
for ( int j = 3; j < root; j+=2 )
if ( i % j == 0 ) {
prime = false;
break;
}
if ( prime )
++count;
}
std::cout << count << std::endl;
return 0;
}