64-bit OS written entirely in assembly

The folks at Return Infinity just released a new version of their BareMetal OS, a 64-bit operating system written entirely in assembly.

The goal of the BareMetal project, which includes a stripped-down bootloader and a cluster computing platform is to get away from the inefficient obfuscated machine code generated by higher level languages like C/C++ and Java. By writing the OS in assembly, runtime speeds are increased, and there’s very little overhead for when every clock cycle counts.

Return Infinity says the ideal application is for high performance and embedded computing. We can see why this would be great for really fast embedded computing – there are system calls for networking, sound, disk access, and everything else a project might need. There’s also ridiculously small system requirements – the entire OS is only 16384 bytes – lend itself to very small, very powerful computers.

With projects that are computationally intensive, we think this could be a great bridge between an insufficient AVR, PIC or Propeller and a full-blown linux distro. There’s just some questions about the implementation – we feel like we’ve just been given a tool we don’t even know when to use. Any hackaday readers have an idea on how to use an OS stripped down to the ‘bare metal?’ What, exactly, would need 64 bits, and what hardware would it run on?

Check out the Return Infinity team calculating prime numbers on their BareMetal Node OS after the jump.

Comments

  1. cdjstyle says:

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

  2. hammy says:

    I’ve been doing my first ever uC course where we are being forced into learning assembly to proram Motorola 64CH11′s… using a bootable Win98 dos USB drive, writing all the code in EDIT, running all the compiling in AS11 and simulating it all in Sim68 ;_;

    It’s like a time machine to 1989 and I want to kill myself

  3. pankromatic says:

    If nothing else, this shows the code bloat that results from high level languages.

  4. anti-fanboi says:

    LOLz!
    Given that we’re talking about competent coders and not pure CS/MBA types:
    ASM execution is ALWAYS faster than C/C++/Java/BASIC etc.
    I wonder how anyone can deride something they cannot actually do themselves. For example the reason you are a good $lang coder is that you can actually “think” in $lang. “Good” code has a poetic nature to it, really good code actually reads like poetry and requires virtually no comments in the same way poetry requires no footnotes. To appreciate poetry you must first understand inherently the subtleties and nuances of the language, be it a computer or spoken language. If you can’t even think in assembler then do us all a favour and don’t pretend to know. Yeah I know, most people think ASM is quite analogous to Klingon… BiHnuchs :)

    The root cause of the problem in my opinion is the inherent lack of will to learn and understand.

    The “cpu cycles are cheaper than coder salaries” meme has the same motivation as the “make the customer be the beta tester” meme. MBA style “profit trumps principles” greed. Yeah I know Microsoft made both these memes mainstream CS but they didn’t necessarily invent them.

  5. cantido says:

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

  6. MrFluffy says:

    Once upon a time I used to write games software in pure 68000 on the amiga. One of the first things we did was capture the vertical blanking interrupt and disable all the basic o/s stuff and take over the entire machine and manipulate bits directly in the hardware chipsets. I’d have written completely non relocatable code if the damn o/s loaders had have kept getting in the way with all their c coded mess.

    Back then you could spot the tight assembler code decompiling someone elses work (its how we learned new tricks!), and the spaghetti code generated by someone coding in C and compiling it after (all the hardware libraries, blech), and we managed to extract some amazing performances out of the machine from hand coding things. It was coding ART, days pouring over instruction set manuals trying to work out how to save a few cycles here and there in loops which ran hundreds of times per refresh.

    I can totally see the attraction of bare metal hardware, and the whole reason I gave up low level programming was the mess of the x86 world more or less forcing c usage due to the need to cover a myriad of hardware setups.

    This, lovely, bare metal, always the same, you could make it sing. I’d love to have a cluster of them for heavy lifting and cut bespoke code for it. Trouble is, moores law would make it out of date in a few years :(

    All power to the peeps doing it!

  7. polossatik says:

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

  8. anti-fanboi says:

    @cantido

    Ruby (or Java for that matter)? Oh boy…. Ruby typifies the “pure CS” I was comparing to MBAs, to me this illustrates how far you’ve missed the point I’m making. I accept I may not have made my point as well as I could have, sorry for that.

    As far as maintaining my code: I doubt you will ever get the opportunity, but if you do you can eat your hat then ;)

    Assembly/assembler… they have been used interchangeably to refer to the language for ages – perhaps longer than you’ve been alive, the point still remains. If you can’t think in a language then you don’t “know” it and if you don’t know it then how do you know it’s the wrong tool for the job?

    If you’ve never seen the poetry in any language or think that concept is a little esoteric that’s your loss ;)

    I can see why one might dread Assembler but I laugh at those who are hysterically scared of it :)

    Peace, Love and mungbeans!

  9. pingumacpenguin says:

    Vi or Emacs ;¬)

  10. Mark says:

    I can see that anti-fanboi doesn’t get paid to develop applications. Unless you managed to fool the management that your company’s business systems must be coded in processor specific assembly. Then I can see that you secured a comfortable future since you are the only one that truly understands the whole system.

    I’ve seen such systems and they may work but not much more. The guys that made it in the first place are long gone and don’t remember anything anyway. When old hardware starts to die out there is suddenly a problem to get the applications to run again. In these cases it’s always faster to start from scratch in a higher level language with a sane software architecture.

  11. cantido says:

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

  12. lexi says:

    This whole thing sounds like a big waste of time if you ask me.

  13. Truth says:

    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.

  14. anti-fanboi says:

    Hey cantido, mate, your hair is on fire! I don’t have an extinguisher on me but I can sort something out if you’d like ;)

    Do a quick search on Amazon for “assembler” and let me know what you find.

    /dig Well what do you know, despite your innuendo and hysteria I was right…. Don’t worry it happens all the time ;) And that self-righteous indignation you’re felling right now – it’s free… you’re welcome :D

    I’m NOT saying Assembler is the right tool for EVERY job, please read what I said. I agree in general with your argument about the right tool for the job, but if you don’t know assembler and you’re making an OS (or an embedded device) you’d best leave the design decisions to those who are not afraid of the assembler boogie man ;)

    “like a bare mental MCU project” see you do have some idea of poetry :D

    Just because you don’t get my point doesn’t make it bullshit. Isn’t that bigotry or is it ignorance, I forget – English isn’t one of my best languages, it’s too “loosely typed” – I think you guys call it. I prefer C.

    /dig Actually, if I said you’re starting to sound like a Ruby dev, would you get what I mean ;)

    If I substituted “elegance” for “poetry” would it help? It’s not exactly what I mean but it’s better than your assumptions.

    /dig You referred to GCC as a language just to be ironic right? :D

    @Mark….. Um…er…. would it help if I typed slowly? We’re talking about writing an OS in assembler not business apps or online shops. And what I do for a living is irrelevant to my point, right?

    I’ve worked on such messes too. Let me assure you: sane decisions were made at its inception which may or may not be relevant any more. Ever wonder why it takes 100′s of MHz or GHz (sometimes clusters of same) based “sane software architecture” to replace a sometimes kHz based “mess”?

    Cheers all.

  15. cantido says:

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

  16. ASMcoder says:

    First off great project.
    But i have never heard so much rubbish, probably written by people that have never written anything in assembly.
    This OS for a start will not run any faster (in most cases slower) for 99% of the task’s that an OS needs to preform, it may do things like boot fast but thats just because of size.
    Writing apps is very easy and a lot of fun, thing’s like debugging are no problem when you have coded the whole OS yourself unlike higher level language’s every bit of code is in most cases written by you so when you find a bug or a problem you know that the problem is down to you , unlike higher level language’s where it could be hidden in some lib.
    The next miss conception is about portability, yes we know that asm is not very portable, but we are talking bare bones here i could port this OS as it stands to a ARM in less than three months and as every OS needs to be optimized for the processor that it runs on this works out better.
    I have spent ten years writing OS’s for many processor’s including x86 in full ASM, and the thing that non ASM programmers just carn’t seem to get there head around is that ASM is easy and fun and most of us do not use it to make things faster in most case’s its not, size is different that is one of the biggest advantages over higher level languages .
    Rant Over

  17. anti-fanboi says:

    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.

  18. Olivier says:

    @ASMcoder: you should get a new pseudo because you don’t know assembly. You can’t port X86 asm in any ARM without rewriting the whole thing.
    So, it’ll take you much more than 3 months to port this OS to any other processor. And I’m sure you don’t know every specifics instructions of every processors, so it’ll take you a lot of time to understand every optimisations tricks of this OS.

    @anti-fanboi: here, you just proved you have never commenting anything. Comments are BEFORE the things to be commented, not AFTER.

  19. Sam says:

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

  20. ASMcoder says:

    @Olivier, Then what is this http://www.dex-os.com
    And i ported it to ARM in just over 6 months, my OS is 52k.
    Your telling me that a OS thats about 8k or 9k, can not be ported to ARM, in 3 months.
    We are not talking windows or linux here.

  21. Ugly American says:

    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.

  22. You can’t just run this on a propeller or a pic or an ARM. You obviously don’t understand the concept of machine code.

  23. bowlinbd says:

    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.

  24. Multician says:

    Ugly American writes:
    ————-
    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.
    —————

    In fact the overwhelming majority of Multics was written in PL/1, with only a few hundred lines of assembler. MCP is widely regarded as the first OS largely written in a high-level language.

    In general, the only time anyone other than a hard-core supervisor (essentially the Multics kernel, in fact the part that ran in ring 0) would need to write in ALM (the assembler) was for writing a “gate”, the program that allowed you to call code in an inner (i.e. more privileged) ring.

    And most of the HCS was written in PL/1 for that matter.

    Writing assembler code is something that every serious computer scientist should know, in principle, how to do,

    But, unless there is very, very good reason, they should never actually do it after graduation.

    The development time is too great and the maintainability is close to zero. As my students have heard me observe any time, assembler is a “write only” language.

    You can learn more at http://www.multicians.org/ – you can even browse the source code and count the lines of assembler if you want to…

  25. DeeplyShrouded says:

    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.

  26. Old duffer says:

    @Anne Nonymous – been there, done that. Google for TAOS or wikipedia for Tao systems / intent.

  27. virgil says:

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

    BTW it fits on a floppy.

  28. wardy says:

    I think writing a usable OS in assembly is cool enough in itself, that’s a significant accomplishment. However I doubt anyone is really likely to adopt this as a serious number crunching platform. It is efficient NOW but it can only become less efficient over time as new modules are added and hardware support is needed.

    Forcing people to write device drivers or comms protocols in raw assembly is asking too much and will be prone to errors. Lets not forget that despite it’s many blemishes and imperfections, Linux (or any modern free OS) is actually already pretty well optimised where it counts.

    A+ for effort but I don’t expect we’ll hear much about this being taken up seriously by the industry any time soon.

    It’s still cool though.

  29. darkore says:

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

  30. zimm3rmann says:

    But can it run Crysis?

  31. Bob Mackin says:

    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.

  32. Vigilante says:

    These would come in handy for complex calculations like robotics or autonomous UAV.. i think with 64bit you could calc all the algorithms much faster or even make newer, better ones that wouldnt even run on lesser hardware.. i am excited..
    and like that ‘dual’core arduino, if we do a 32bit shield for a 32bit processor, couldnt we run baremetal on it then?

  33. wardy says:

    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.

  34. Alan says:

    VMWare Server uses a mini-linux base, you could uddate that. Or change VMWare Workstation.

    Basically, streamline the path between (multiple) virtual machines and the hardware.

  35. abobymouse says:

    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.

  36. Decius says:

    @MattE

    Thank you for answering, I didn’t know this was written for x86 exclusively.

    Well if there is an ARM port of an ‘ASM OS’ under 100k then put that on the PSP or RB26DETT “ECU”,ARM Boards – which ever xD

  37. Dan says:

    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

  38. Huh? says:

    Here’s code that not only calcs the number of primes between 1 and 300,000 in less than a second, but returns a list of them. Also, it is running on a crappy desktop using Windows 7 and C#:

    public static List GeneratePrimesNaive(int n)
    {
    List primes = new List();
    primes.Add(2);
    int nextPrime = 3;

    while (primes.Count < int.MaxValue)
    {
    int sqrt = (int)Math.Sqrt(nextPrime);
    bool isPrime = true;
    for (int i = 0; (int)primes[i] n)
    break;
    }
    return primes;
    }

  39. Megol says:

    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.

  40. Darron says:

    Okay, look… this -SHOULD- be a good lesson in the folly of programmer arrogance.

    I did 2 minutes of research to turn up a highly unoptimized C++ prime search function. I rigged it up to do this “from 3 to 300000 by 2s” test for primes, and what do I get?

    1000 passes in 51 seconds. 0.051 sec each pass.

    I think that says it all. If you can’t take a couple minutes to look up how to write a prime number test, how on Earth are we supposed to believe this OS is any good?

    If I can whip up something in 5 minutes via a Google search that outperforms your super tuned OS by a factor of 1300… what does that tell you about misdirected effort? (Although, to be fair I’m running on a 2.5GHz Core2 Duo vs. your 3.2GHz Pentium D… so maybe we should cut the performance factor in half or a third)

    Oh, and… how’s this for power usage. I cross compiled my crappy prime app for ARM and ran it on my custom 454MHz iMX283 ARM SBC running a pretty unoptimized Linux 2.6.35 platform and I get 5 passes in 19 seconds with SOFTWARE SQRT. It uses 1.25 watts to do this.

    So, 17.6X speed with a processor probably 20 times crappier than yours, using 144 times less power.

    I am ABSOLUTELY not claiming to be any good at any of this, either.

    You obviously have drive… go find a way to direct it more usefully and you can potentially go far.

  41. IJ Dee-Vo says:

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

  42. Toddo says:

    The A-Team was hired by Gawker Media to take down LulzSec. They did, but now Lulz has targeted a total takedown of Gawker Media.. this should be fun!

  43. ashish says:

    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

  44. ashish says:

    @zimm3rmann

    man i just laughed my ass off at your comment

    i bet they could run crysis surely.. one who’s graphics would get displayed in characters

  45. Luposian says:

    Anyone who is interested in working on making BareMetal OS more useful and functional as an end-user OS, reply. I have some interesting ideas…

    • ashish says:

      i have an idea of my own. Of making an OS which does exactly what we want to, well, and other necessary processes to support what we are doing, but none other then that, to save power and efficiently give a unique computing experience.

      From that, our laptops and tablets etc could go on for days on end on a single charge of a battery

      i could reveal a more of my idea if you are interested. But also let me know of what you were going to talk about.

      • Luposian says:

        The only way to achieve that, would be for the computer to only be working when we’re doing something. And then it goes into standby/hibernation as soon as it’s done doing that. The problem is, you have to see what the screen is showing, which requires power to display. and coming out of that “frozen” state takes a little while. If it were nigh instantaneous (1-2 seconds at most), it would be better.

        If you’re referring to the computer KNOWING what we want it to do, that is impossible… it can’t read our minds.

        My idea (or part of it), is to create a 64-bit version of the Atari ST’s OS (at least in similar appearance). The code is tight and fast. How fast would the Atari ST GEM interface operate if it were written in 64-bit assembly, on today’s 64-bit hardware? I’d say it would be BLINDING! And I’d love to see it!

        The other part is to create a 100% secure OS. And I mean, from EVERYTHING. Hack attempts, viruses, trojans, spyware, etc. Being an obscure OS (i.e. not Windows/MacOS X) is one way to insure you’re fairly safe, but it doesn’t protect you, entirely, if they decide to try and attack you.

        Now, true security is not achieved the way it’s being done now. You don’t stop viruses/trojans/spyware/hack attempts, etc. by intercepting what they LOOK like (code signatures, etc.). Oh, sure, you CAN (and it’s done this way), but this is an ongoing battle. New viruses, trojans, spyware, etc. require updates to the app to intercept those programs BEFORE they attack you. Sure, it’s job security (always writing new interceptions), but… what if you NEVER had to write any antivirus or spyware apps at all?

        This can’t be done with today’s OS… you’d have to totally rewrite them…

        But, with BareMetal OS… you don’t NEED to rewrite anything, because there’s almost nothing there! Few drivers and apps. Now is the perfect time to create an OS that is 100% secure, from every possible point of entry, from every possible type of attack.

        Impossible? Nope. Unless, of course, no one is willing to work on the OS to accomplish it.

        • ashish says:

          can you give an approximate measure of how many watts per process are used up in a Windows machine, say, running on Intel p8600 (thermal power dissipation=25W as seen on Wikipedia)

          i’ve seen from task manager->performance tab->resource monitor that explorer.exe uses 0.10 “Average CPU” (cycles?)
          i don’t know how i will calculate the dissipation in watts for that particular process.

          If you can give me that, i will tell you what i actually meant, by giving you paradigmatic introduction to my idea of an super energy efficient OS

  46. Mattieu says:

    One of the problems with this type of thing it is capitalises on naivity obout what an operating actually is: It’s possible to write an OS in just a few hundred bytes of memory, not 16,384. All it needs to do is boot. Once you know how to write software to the boot-block you’re done.

  47. Bo says:

    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.

  48. peter says:

    How hard would it be to adapt BaremetalOS to host other OS’s? So I could instantly switch from OS X to Windows to Linux etc without a cumbersome host OS + VM or multiple boot options as currently practiced. This is where I would go with BaremetalOS! One machine and multiple OS’s without any lag or rebooting. With today’s hardware and memory capacities I can see this is the next step in computing.

  49. josh says:

    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;
    }

  50. Charles says:

    The detractors aside this seems to be a note worthy FOSS project which seems quite suitable for individuals owning x86 hardware interested in activities such as audio/video encoding as well as Bit/AltCoin mining which in the above cases would benefit from monotasking. Audo/Video encoding and Coin Mining are extremely CPU intensive. Anything that can give these applications more clock cycles is a good thing.

    I would like to thank the posters here for making me aware of other assembly based OS’s. I was unaware MenuetOS and it’s fork KolibriOS existed.

    Imagine the end-user utility of having a port of x264 and or Handbrake’s CLI to Bare Metal. In the end the process is the same as using an OS with far greater overhead except the efficiency will allow the process to complete in Bare Metal faster. This is a boon to the end-user should this scenario ever come to fruition.

    I would also imagine anyone else with any other kind of vast media collection they need to convert which is an immensely time consuming process would likewise see potential long term benefit out of this OS’s mere existence.

    Another factor is that BitCoin and the other AltCoins can change their algorithm to become unfriendly to FPGA, ASIC and GPU based calculation. Therefore as more Coin types are created which require CPU calculation the need for an environment that is efficient for doing that task within increases.

    If Bare Metal can at the bare minimum provide an OS working environment that is efficient for Coin Mining then it will see success long term as Coin Miners seek to eek out every last bit of performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s