MenuetOS 0.74 is released and includes a Tiny email server, improved Http/Mp3 servers, Fasm 1.48, improved protection, skinning and font additions, Minesweeper and more. The OS is written in 100% assembly and is running off a floppy disk. However, developers are now adding support for a C library and they are looking for more developers to help with fixing the bugs and adding new features.
MenuetOS 0.74 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Am I missing the point? Why would you add C to Assembly? His whole deal was the total OS was in machine and not compiled with a load of other stuff. Seems to defeat his total machine code idea to just another hobby OS. It ought to be a C to A converter.
i think they call that GCC
I thought that was C to Machine Code
You can have it output to human-readable assembler using the -S switch
Am I wrong or the standard lib they want to make is for compiling user space applications only ? And that has nothing to do with kernel/OS development of whatsoever ?
If it’s the case, I don’t understand the complains here …
You are right, I don’t understand the complains neither. It’s crazy to write a browser or office apps in the assembly and it will be very insterest if anyone dare.
Read forum there – many times people asked about possibility to write for MenuetOS but in c. OS still will be in assembly, only some applications will be in c.
As for C to assembly converter, I don’t see any benefit here, unless you want to go through your entire assembly code again and manually optimize the code. But compiling to binary, or compiling to assembly source, there’s absolutely no difference …
Did not know that. Thanks
I use the assembly output all the time. Mostly to see what sequence of operations prodcues better instruction sequences for what I’m doing. And very rarely to hand optimize code.
What I have been reading for that OS is that there are still some people who believe that every OS and application can be written in machine. The benefits include very very small system and apps, so less bits equals much faster work. The downside is that it isn’t for common programmers. There are quite a few diehard programmers that can still write in machine. I guess it would expand the use of his OS to have more apps but it sure would be cool to see an OS like beos crunched down to pure assembly. MenuetOS has some real nice features and getting better all the time. Great work there.
Hmm. Forgive me if I sound ignorant, but wouldn’t having the entire kernel of your OS able to fit into your CPU’s cache, with room to spare, give you a decent speed boost? If this is an obvious question, I beg forgiveness, but I’m a neophyte at asm still, though I’m getting better.
“I use the assembly output all the time. Mostly to see what sequence of operations prodcues better instruction sequences for what I’m doing. And very rarely to hand optimize code.”
That’s a weird practice, that sound to me a huge time waster. When I don’t care about speed optimization, I don’t care about assembly output. If I do care about speed optimization, and that it’s critical to the point I need to work at assembly level … then I simply code in assembly …
They did it because they only way they are going to attract developers is by creating a C library. No developer in their right mind is going to develop any kind of substantial software for the OS if they havwe to do it in assembly.
“There are quite a few diehard programmers that can still write in machine.”
There’s no real point to program in machine directly, assembly is what’s for.
The big issue with an OS like MenuetOS purely written in assembly, is that they are 0% portable. It’s a funny geeky project, but it’s a big no futur as for anything useful.
I much prefere toying with hobby OS that intelligently mix C and assembly, using each languages for what they are the best at.
“The big issue with an OS like MenuetOS purely written in assembly, is that they are 0% portable. It’s a funny geeky project, but it’s a big no futur as for anything useful.”
The other big issue is that they are very bug prone, and those bugs are often difficult to track down. The few times I played with MenuetOS, a wayward application could bring the entire OS down very easily.
“They did it because the only way they are going to attract developers is by creating a C library.”
Why do they need to attract developers? How much more do they hope to fit on a floppy?
It truely is amazing what they have done with 1.4 MB of space, and I am thilled each time a new version is released. Keep up the great work!
-Bob
“Hmm. Forgive me if I sound ignorant, but wouldn’t having the entire kernel of your OS able to fit into your CPU’s cache, with room to spare, give you a decent speed boost? If this is an obvious question, I beg forgiveness, but I’m a neophyte at asm still, though I’m getting better.”
This is not the way it works. You cannot address L1/L2 CPU cache as you do with memory. Caches use a hardware process to (pre)fetch and store blocks of central memory.
Very simple cache example follow, please experts, refrain from bulldozing.
——————————————————-
Lets consider this fictionnal 32bit CPU where each effective address points to a byte. This CPU has a single 32Kbyte cache. Each time cache is accessed, the CPU reads 4 bytes (32bits) of data simultaneously.
When a cache miss occurs (data is not in the cache), a memory access is started and 256 contiguous bytes are fetched. That’s eight 32bits values.
Each 256bits forms a cache line. With a 32K capacity the cache has 1024 lines.
Central memory, on the other hand, has a theoretical address space of 4GB. Only 16MB are actually populated by memory modules. This effective space can be viewed as composed of 512 Kilo-blocs of 32Bytes (256bits).
(16M / 32 = 512K)
Thus a central memory bloc would fit in a single cache line (surprise!).
Every time a cache miss occurs, the CPU will flush a cache Line (usually an old one) and replace it’s content with the memory block containing the requested data. The Idea being that the next data to be requested has strong chances of being contiguous (especially in instruction segments).
——————————————————–
End of very simple example
Modern cache architectures are Multi-leveled and use advanced associated mapping techniques to cover has much central memory ground as possible. The cache is fractionned in smaller units that are associated to regions of memory and contain lines taken from these regions.
That’s in a nanoscopic nutshell)
Hope this helps,
ASMatic.
If anyone has a link to an online ressource on how modern caches work, please post.
We really really need a preview button or an edit post function.
Hope people can get the point in spite of the typos.
Yeah, like x86 is going away anytime soon….
Actually, a properly coded ASM project is very easy to port since most processors have basic memory, integer arithmetic, and logic functions.
ASM is also just as easy to debug. You are able to use basically any debugger you want. Though there might be some extra instructions to step over. Big deal. I use the Watcom C/C++ debugger myself.
ASM’s weakest point is with objects and typed data. A few macros in NASM and presto – problem solved.
The “crashability” of the operating system has nothing to do with the language it was programmed in. It’s the design of the operating system.
Check this out:
routine main
beginr
program.open
environment.get query_string
cgi.parse eax
variable.get command
mov [command_ptr], eax
program.close
endr
A little cryptic if you’re not used to it. It generates optimal code, compiles 100% in NASM with my macros. No kidding.
Menuet will remain 100 % assembly. And no other languages should be associated with Menuet development team.
this project is complete: http://www.geocities.com/kirkalx/menquake/
… and … you get at least 30FPS!!!
“Actually, a properly coded ASM project is very easy to port since most processors have basic memory, integer arithmetic, and logic functions. ”
I disagree here. Going from pure x86 assembly to port to, say, Hitachi architecture or Motorrola, there’s WAY too much difference in the registers, system flags, endians, memory mapping, etc. It’s definitelly not an easy task, and require major re-write.
This is a fascinating project. I downloaded and made the flopy disk yesterday at work. It booted and ran without problems. I can’t say that for many other project (or Linuxy) OSes that I’ve tried. This thing is a great proof-of-concept (that a nice looking and feature filled OS could be made much smaller than the 2GB monsters we have dominating the market).
I’ve written C library for MenuetOS, because I wanted to port some games to MenuetOS. Currently I’m trying to port Doom. I don’t want to develop core of Menuet using C. It doesn’t require C library. C library is only an option. You don’t have to use it if you don’t want. I want to port GCC 1.42 too, because it’s quite small and usable. The hardest thing to do is make gcc output fasm compatible assembly code.
As rajan r has correctly stated, x86 isn’t going anywhere soon. Writing programs in x86 assembly guarantees a rather large amount of host platforms without having to worry about portability —> it’s a very important and ineresting assembly and programs written in it are very viable, including MenuetOS. It won’t run on a MIPS anytime soon, but I don’t think anyone’s particularly worried about that.