The Unununium-based distribution FRuSTRaTiON, version 0.3, has just been released. Features improved console support, new keyboard code with unicode support, ext2 file system support; and it can now run applications. Unununium is a Single-Addressing-Space environement entirely developed in 386+ assembly with an emphasis on speed. The system is entirely dynamic: Any component of the system may be reloaded at any time; there is not even a static nano-kernel. Channeled IRQ, dynamic linker, memory allocation, 3d engine and communication channels are only a few of the elements present in the system. Multiple virtual consoles support, fixing the thread engine and starting the development of a GUI are their current development priorities.
Unununium:FRuSTRaTiON 0.3 released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Did someone say…ITS FAST!! ? Cause it is, its DAMN fast, it runs just as fast on my 386 as it does on any PC, cause it hardly uses the ressources that the 386 has never mind requiring more. Out of the box it cant do a whole lot, but it shows that it has GREAT potential if you ask me. It will do much as people start noticing and start coding apps for it (any takers?)
Dude. Its in ASM! I was looking through the source, and by god they wrote an implementation of ext2 IN ASM! Damn impressive, but fairly useless. First, most compilers optimize better than human coders anyway, plus stuff like filesystems, which are disk bound) gain absolutely nothing from slightly faster (if that) code.
Umm… I think this guy would kinda know what ASM is considering he is one of the project admins. Hello? Come on if you know something about the project then you can talk about it.
Sure 0.3 is going to seem useless to somebody who has never tried to code what has been done especially in ASM.
Hey man, C compilers are optimized, but they create so much overhead that it simply cancels the optimization. And btw, human brain is better at optimizing, because this is not COMPILATION, but completely ASM design… so it basically is faster by the way it is designed for.
Rayiner Hashem: I can see how you could say that, since your puney C brain probally isn’t cabable of knowing what prefetch is, or how to break up dependancy chains, or how to use SBB to eliminate conditional branches, or LEA to do a shift and two additions in one clock cycle. You are right, most people are like you and are far better off substuiting compilers and stack frames for brains. For those of us who own a computer rather than the other way around there’s ASM.
Most compilers do better code MY ASS. In Uuu we’ve freed up ebp for our own use (C needs it for its useless enter/leave instructions that it feels the need to execute every 2nd cycle
). That gives us 7 General Purpose Registers that we can do whatever we feel like with. C uses the stack to pass all its parameters, we use registers, it limits us abit yes, but we can always use the registers AND the stack.
Storage medium drivers optimization means a ALOT when it comes to speed. We’ve seen it bigtime when we changed our floppy driver for an older one to a newer one. The new one is like 5 times faster (which you can notice at runtime). When it comes to filesystem drivers, those too need to be optimized to gain the actual performance differences between filesystem types.
Sure critique Uuu, but its being coded in Assembly doesnt make it any less good of an OS. Sure, it aint portable, but i know that all my hardware is x86 compatible, dunno about you, but i dont know of many people that run anything else.
That’s a 30-year old debate that has no absolute answer. First, so as to return some credit to C compilers: you can free up ebp (or whatever the frame pointer is on your architecture) on most compilers. gcc just needs to be told -fomit-frame-pointer. You can also pass function parameters in registers (at least with gcc) with -mregparm=n, where n is the maximum number of registers to be used for storing parameters (up to 3). These two options (plus -O2, otherwise the compiler will not try to generate optimized code, but code that can be easily followed by a source-level debugger) bring the result closer to what you can do with straight assembly (note ‘closer’, not ‘equal’). The compiler has the advantage that it will optimize the same way all across your code, and not get tired or decide this function is not worth the hassle, etc. On recent, complex architectures (with prefetch queues, delayed slots (mips, sh) or branch prediction (intel), two levels of associative cache, etc.) it will probably outdo most humans.. Of course if you’re really good, it will not outdo your assembly code. Provided this is the case with the people writing UUU, that’s a really neat achievement; congratulations guys.
Before you deride ASM coding and claim that C compilers always produce better code, please take a look at what your processor provides, what your languages allows you to do and (importantly) what is the actual code that is produced by your compiler with all optimisation flags turned on.
For example, it is simple and neat to do 64-bit arithmetic on ix86 processors in 32-bit ASM, the ix87 family of FPUs provide far better support for IEEE 754 floating-point than any mainstream language (C99 comes close) that make useful error-analyses possible, and so on. Do take a look at some darn good ASM code written especially by “demo coders”.
And ASM, especially 32-bit protected mode ASM, is not at all difficult to code in and understand, unlike popular belief. Read Knuth’s classics and code some of your own programs in ASM. I guarantee that you’ll gain insights about computer programming that is IMPOSSIBLE to achieve via a “high-level” language.
My 2p.
your all scary.
I see this is another single address space system, see technical intro
for some interesting stuff about linking that also gets into this “segment”
thing you x86 guys talk about. FYI, P_developer et al. from the AMD roadmap
discussion. I don’t know if it’s actually using virtual memory, or if other
issues normally associated with SAS even apply here, so I don’t know whether
to be amazed that they’re running SAS on 32 bit address registers. The disk
doesn’t seem to run very successfully on my computer.
Wonder if someone could write a Smalltalk VM for it, so they could get some
software written.
whoa great. 386 assembly. so is it optimised for a 386, 486, 586 or 686 class?
is it optimised for my duron, taking its cache size and pipelines into account? or is it targed at my p4? so when XXX releases new x86 chip ZZZ, with new optimisation rules, what happens to uuu? oh its getting branch stalls all over the place, and it cant just be recompiled to get the best of the new cpu it has to be all re-optimised. wow. i’m impressed… not really. nice technical achievement, but its just one of how many other hobby os’s written in asm for the sake of being written in asm?
now if it was PPC, mips or sparc asm, then i would be impressed. really impressed. but x86 asm does not impress me.
i’ll dl it and test it on vmware3. will i look for bugs in a hoard of ugly asm? nope.
oh and raptor, you said you use register calling where c compilers dont. erm. hellloooo my watcom compiler thats YEARS old does register calling…
i’d rather have a good algorythim and smart algo, than a super fast ‘i save two clocks here’ routine.
“Storage medium drivers optimization means a ALOT when it comes to speed”
erm. wow. a floppy + hd can only write so fast. if your using dma (i hope your doing dma and not doing PIO), then how much speed increment do you really think you achived? to say “5 times faster” then your old driver was poorly written.
I dont see the point in creating an OS like this. Ok if it was just a small hobby project created just for fun, but these guys seem to be serious about creating a complete OS. What are the goals of this OS (besides speed which is not very useful in itself :-)?
Some disadvantages I can think of right now:
– Assembler: not portable at all, cannot be optimized for new processors, very time demanding to program in, code is very hard to maintain
– Single address space: no memory protection, if one thread/method writes to the wrong address the entire OS is dead.
Is anyone forcing any of you to use this OS? To program for it? To install it on your grandmother’s PC? No? Then, what’s the problem? Why can’t you just either ignore it if you don’t like the concept, implementation, programming language, phase of the moon, whatever, *or* give appropriate compliments to the programmers for an impressive job well done?
So what if it’s “Yet Another OS” ??? It may never be anything more than a hobby OS; it might find a good niche market; who knows where it might end up? Linux started out pretty humble, from what I recall – nothing more than a scheduler/task switcher, and look where it is now.
Everyone who’s kvetching about how horrible ASM is/how wonderful C/C++ is for writing an OS, go ahead and write one yourself. Otherwise, kwitcherbichin!
‘Whats the point of Uuu?’ Read the website, its all there. ‘Are we serious?’ Yes, we are, we believe in what we are doing. ‘For the sake of writting it in assembly?’ heh, we prefer ASM over C, i find it easier to code in ASM, much easier. I was written an app for a company in VB, dear god i missed asm or atleast give me inline asm! Not portable? Who cares is all i have to say to that one. Isnt optomized for newer processors? Not entirely true. We favor AMD processors cause Intel is in bed with MS and also make crappy processors. Because the code runs on a 386, it doesnt mean that i wasnt coded with Athlons in mind. We usually put abit of work to make sure we dont clobber the nice branch prediction on the Athlon, and try to stay away from its vector instructions. As for disk stuff.. if you are writting a single-threaded OS, then disk driver speed doesnt make a difference really. 0.3 that was released has a single thread yes, but 0.4 should be multi-threaded, in which case, you dont want to waste too many cycles on disk accesses as other threads could be using those cycles.
SAS on 32bit registers… why not? It gives us 4gigs of addressing space. Seeing how little RAM we use at the moment, i dont see the need for swapping at the moment.
As for the image not working properly on certain machines…We have had an issue that we only discovered yesterday, that caused certain keyboards (mostly AT, but some ps2) to not function at all once inside Uuu. Seems we have our older memory manager to blame for that (ironic how its name is actually noblame memory manager). With our new and improved memory manager (oxygen wave 3), the problem goes away.
Memory protection: why is it needed? so that you dont pass wrong pointers to other functions? Seems like you should be passing wrong pointers to start with. Keep track of your pointers and you’ll be fine.
Like i said, if you have something to say about the OS, fine, say it, but please leave ‘C is bettah’ out please. We prefer assembly, and we believe in it. Except for that fact that its unportable, there is no real reason for asm to make it any less good of an OS.
Optimization wise, there is many thing one can do to actually improve performances on more than one processor. Using dec ecx/jnz instead of loop improves performance on almost all processors. Similarly, using lea to compute eax + ebx*8 + 44 instead of doing a bitshift and 2 additions, taking care of properly interleaving 2 instruction streams to better make usage of dual pipes, are also solutions that are “portable” across various x86 cpus.
Making your code smaller, while keeping it as fast at runtime makes your entire system load faster from the disk. Since storage medium is normally the slowest part of the entire system, loading an extra sector or not will make a difference, in how many cycle from the “ENTER” on the command prompt to the execution, that can be in the short/medium/long time major.
Most C processors, if not all, are better than most humans in optimizing code, that is true. But again, how many of those humans can write good assembly code? not a whole lot from my own experience.
I have been writing in assembly for the past 5 years, intensively that is, and I can say that only in the last 4 or 5 months did I start writing “good” code. When you know some tricks, you understand cpu design and once you developped good commenting techniques, writing assembly will most likely take barely more time than writing in C, if it takes more time. Many of you might remember _vulture (AKA Sean Stanek), who proved more than once the above, developing faster a specific algorithm using assembly than a supposed equivalently good C programmer.
Register passing in C is ugly, painful, will most likely result in more time spent on your code (than your asm guy doing the same) and you are restricted to only a few of the registers available to you. Sure it does speed things up compared to using the stack-only method, but between me and you, it could still be improved by using more of those registers.
Last note is, if your code is hard to maintain (and this could happen in any language), you might want to consider changing your commenting techniques, learn how to re-organize your code, split large code in multiple source files, etc.
my 0.00000000000002 cents.
EKS – Dave Poirier
And then someone runs the code on another x86 compatible CPU and all the assumptions you made about what was fastest aren’t appropriate.
I find it funny how, when an os is developed in asm, the os value and design isn’t the important point to fight on, but how the asm vs C is taking precedence.
Don’t you guys have any better knowledge to share than “asm sucks, c ownz” ?
Hmm.. This kinda sounds like http://www.v2os.cx/“>another posted here on http://osnews.com/“>osnews user” rel=”nofollow”>http://vp.dhs.org/specs.php?spec=64″>user interface? Will GUI apps work in a terminal enviroment? The http://www.v2os.cx/“>other sounds more promising, even though not much code has yet been made.
But it’s pretty cool anyway. When there’s TCP/IP support, I’ll start using it.
LNN: I’m sure you just made yourself a very good reputation here
I like ununium project. I like asm (although i’m not even good in it). I don’t like ppl saying “another os, what for?” or “it’s stupid”. Don’t like it? Write Your own! You can’t? So shut up!
mov ax,13
int 10h
[do stuff]
mov ax,3
int 10h
mov ax,4C00h
int 21h
I’ve had to write minimal amount of assembly code in my time, and I’ll stick with higher level languages. I don’t even know if I would be a programmer if I *had* to program in assembly. You assembly guys are hardcore, that’s for sure. Good luck with your OS, and hats off to you guys for sticking with ASM.
There is a great truth about online discussions: Whenever the discussion turns to “which computer language is the best”, the discussion quick degenerates in to a useless flame war.
The best language is the one that you can use best.
Finally, Hitler would probably have preferred Visual Basic.
(For people that don't understand the above paragraph: please look up Godwin's law)
LNN: If your talking about V2_OS being the similar OS I’m gonna lmao at you.
All the programmers that made V2_OS somewhat “good” (if you can call it that), are working for Uuu. Look at V2_Gui project page, and most of the other projects for V2 and you’ll find similar names listed. What that means is that V2 is riding on the fame of broken promises or one big lie. Development for V2 is moving so slow 2 years ago they were talking about .70 and it’s not even close to release.
I have three machines here, this floppy refuses to boot on two of them (on this AMD XP machine it gives a nice error message, on my Pentium 500MHz it freezes the system after reading the floppy for a bit, and on my 933MHz system it seems to boot successfully but I can’t seem to type anything).
But it’s fast!
Didn’t have a chance to blink before it loaded and gave me a prompt.
ps What does Hitler have to do with Visual Basic anyway???????????????
>and on my 933MHz system it seems to boot successfully but I can’t seem to type anything).
Maybe because your keyboard is USB? Try with a standard PS/2 keyboard.
I didn’t get jBett’s original response to me. I wasn’t critizing their use of ASM, I was just taken aback that there was so *much* ASM. ASM isn’t something I’m used to seeing, and it was just a little weird to see a whole filesystem written in it.
BTW> I don’t want to start the whole C vs ASM debate, but I can definately tell you that modern compilers (Intel C++) can kick most programmers’ asses when it comes to optimizing programs. First, C (and by extension most of C++) creates very little overhead. Most of the language features map very nicely to what is already present in the hardware. The real benifet of ASM isn’t (wasn’t) minimizing overhead, it was low-level optimization of code. Scheduling instructions at the right time and whatnot. That kind of thing is very detailed work, and modern compilers do it very well. Plus, they can easily adjust to varios processor differences wheras ASM must be rewritten in the same cirumstance. For example, on older (386-era) x86 processors, the string move instructions (eg: rep stosd) where many times faster than the standard instructions (eg: loop mov) with modern x86 chips, however, there is no difference. Likewise, lots of things that used to be fast are now slow. Plus, each chip has different ideosyncronasies that can make or break performance. The P4, for example, takes a huge penalty for incorrectly guessing a branch in the code. No human being can possibly be expected to keep all of these things in their head, and thus concentrating on good algorithms (which the compiler can’t optimize) and letting the compiler take care of the details ultimately leads to the fastest (and not to mention easiest to maintain) code.
Rayiner Hashem: I can see how you could say that, since your puney C brain probally isn’t cabable of knowing what prefetch is, or how to break up dependancy chains, or how to use SBB to eliminate conditional branches, or LEA to do a shift and two additions in one clock cycle. You are right, most people are like you and are far better off substuiting compilers and stack frames for brains. For those of us who own a computer rather than the other way around there’s ASM.
>>>>>>>>>>
You’re right. I have no desire to keep all of those things in my head (though I have done ASM programming and know what you’re talking about!). Since the compiler can do all of those things for me, why should I bother? Read up on the specs of Intel’s C++ compiler. It does things that even human programmers wouldn’t think of. We have tools for a reason. Tools are what makes us human. Is a chef any less of a chef (or, is his dish any better?) if he wimps out and uses a knife to cut the steak instead of ripping it with his bare hands?
First, I’m not criticizing any OSs for being in pure assembly. That’s their business. I’m simply pointing out that ASM isn’t going to be appreciably faster than C code. Plus, when those gee-whiz new processors come out (with their fastly different instruction scheduling requirements) ASM-only OSs will have to be recoded to take advantage, while a C OS will simply have to be recompiled with an appropriate compiler. Lesson number 1 of OS design: A good, general algorithm is faster in the long run than a highly optimized one that sucks as soon as conditions change. Lesson number 2: Spend time where the time needs to be spent. Make, GCC, Autoconf, etc, all exist so you can spend more time thinking about the code (improving design/algorithms) and less time actually implementing it.
Rayiner: My first message was explaining that you were trying to tell one of the head developers of Uuu that anything coded in ASM is fast. Well I just found that pathetically stupid of you to have posted about this OS without even looking obviously at the Uuu Webpage.
I wasn’t trying to tell any head code of any OS anything! I simply remarked that
A) I was astonished at seeing so much code written in ASM
B) ASM really doesn’t gain much over C.
The second comment was not aimed directly at the UUU guys (its their OS, what they do is their business) but was an abstract comment about the two languages in general.
lol@LNN (Our dearly loved V2 Spy). We all know that Uuu is actually going somewhere. V2_OS 0.7? Whens that coming out? Before Windows .NET possibly?? Anyhow, good luck to V2_OS, it was a cool project, and its a shame to see it in its current position (where it has to beg for coders). And also… Uuu in no way resembles V2_OS. IT does nothing the same as 0.64, and does virtually nothing the same as 0.7.
Nope. Using a PS/2 keyboard, not USB. Odd how it would boot and not allow me to type.
I think it’s cool that someone codes an OS in ASM. But as many people say here, I dont think the performance gain using ASM over C is that great (and there are many disadvantages). To test this, I made a little program in C:
int x = 0, y = 10;
for(int i=0; i<100; i++) {
x = x * 31 + y;
y *= 3;
}
And compiled it with MS Visual C++ using optimization. The resulting assembler code:
0040A2FD mov esi,ecx
0040A2FF shl esi,5
0040A302 sub esi,ecx
0040A304 add esi,eax
0040A306 dec edx
0040A307 mov ecx,esi
0040A309 lea eax,[eax+eax*2]
0040A30C jne main+2Dh (0040a2fd)
I think this code is very well optimized. Maybe you can optimize it more if you have the time, but remember that a C compiler will optimize ALL of your code this well. That’s why I dont think it’s worth the time writing non-performace critical code in ASM. And well optimized ASM code is hard to read and understand.
The assembler code is only for the C loop.
Why are you ppl critisizing the UUU dev team? At least they have something to do. And that’s not blaming other ppl’s work. Unununium is and will be written in assembly and you have to live with this knowledge… So shut up and live happily with your windoze and other high level OS-es, written in C. Keep up the good work – my greets to eks, raptor-32, indigo, hellman, karmah, miro and …
(Damn short memory).
The whole keyboards not working thing should be fixed. If you go to http://uuu.sf.net (i dunno where the HTML tag symbols are on this french keymap), and read the news, there are links to new versions of 0.3 which include a much fancier memory manager. With the new memory manager, the keyboard issue goes away. The reason that 0.3 was released with the known keyboard issue is because we thought it was just my 386 that had problems with it (many times thats the case). And if any of you finds a bug in any of the software, please notify us so that we can correct the issues. Email either [email protected], [email protected] (yes yes, im ashamed of it), or [email protected].
I think LNN was having a bit of a joke there – he knows full well about all that (he should do, he talks to UUU coders and he released tha latest 0.64x version of v2os) – and he knows UUU ownz v2os’ ass.
Thanks to the large user base we just acquired, allowed us to discover many little glitches in our system. We had a few memory corruption that due to some memory and system configuration never got out before, we are now working at fixing them.
You should be able to find the 0.3.1 release sometime tomorrow or at the later on friday night. Again, Thank you all for your bug reports and for even giving us a chance to power your PC once
Keep the updates coming!