Full ASM OS?
Full ASM OS?
How many people are developing their OSes fully in assembly (or at least the main kernel/drivers), and why?
Generally speaking, you can write your hobby OS in brainfuck using a magnetic needle in your right hand and a floppy disk in your left for programming, if that is what you want (as a challenge, for example).
It certainly gives you ASM experience, and can be quite fun if you are good at it. Perhaps you are good enough and your target platform is demanding enough that ASM gives you a real edge in code size. Perhaps you are really good enough to beat a well-optimizing compiler in raw speed, but that is getting more difficult with each new processor generation.
Beyond a certain scope - like, aiming for a generic desktop / server OS, a team larger than a certain size, a lifespan beyond the next few years - ASM is out of its depth. There is a reason why there are embedded systems programmed in Java today, but no generic desktop OS written in pure ASM (aside from, IIRC, the very first versions of AppleOS before Woz had to yield to the realities of business).
It certainly gives you ASM experience, and can be quite fun if you are good at it. Perhaps you are good enough and your target platform is demanding enough that ASM gives you a real edge in code size. Perhaps you are really good enough to beat a well-optimizing compiler in raw speed, but that is getting more difficult with each new processor generation.
Beyond a certain scope - like, aiming for a generic desktop / server OS, a team larger than a certain size, a lifespan beyond the next few years - ASM is out of its depth. There is a reason why there are embedded systems programmed in Java today, but no generic desktop OS written in pure ASM (aside from, IIRC, the very first versions of AppleOS before Woz had to yield to the realities of business).
Every good solution is obvious once you've found it.
I agree with Solar to a point, but then again, if an OS is modular enough, and we're talking about macro assemblers and not something like MS-DOS debug, then what a typical OS really relies on is not C as such, but the standardized calling conventions of C.
Once you force certain semantics on procedure interoperation, force certain method of passing arguments around, and such, programming in pure assembler starts becoming less and less attractive, simply because if you are forced to use a certain convention anyway, you could just as well have a compiler take care of that convention.
It's the same as we go to higher levels really. One of the attractive features of virtual machines like JVM or CLR (whether JITed or not) is taking care of more conventions, which in turn allow more flexible interoperation. Typically for example such a VM imposes certain layout on all objects, which enables things like garbage collectors to work without manually having to tell how they should handle each and every object.
Everybody knows it's possible to have a nice garbage collector running for your manually written assembler code, but who wants to write GC safe code in MS-DOS debug? There's just so many purely mechanical issue that can be given to a compiler to handle.
Personally, if I wasn't happy with C (well I'm not, but I'm not unhappy enough to not use it anyway, I guess), I'd rather write a compiler for a better language, with the specific problems fixed that I don't like, than degenerate myself to writing assembler manually, simply because writing a compiler once means I can have it take care of the trivialities, and let me concentrate on the interesting parts: how to actually get a given task done.
Once you force certain semantics on procedure interoperation, force certain method of passing arguments around, and such, programming in pure assembler starts becoming less and less attractive, simply because if you are forced to use a certain convention anyway, you could just as well have a compiler take care of that convention.
It's the same as we go to higher levels really. One of the attractive features of virtual machines like JVM or CLR (whether JITed or not) is taking care of more conventions, which in turn allow more flexible interoperation. Typically for example such a VM imposes certain layout on all objects, which enables things like garbage collectors to work without manually having to tell how they should handle each and every object.
Everybody knows it's possible to have a nice garbage collector running for your manually written assembler code, but who wants to write GC safe code in MS-DOS debug? There's just so many purely mechanical issue that can be given to a compiler to handle.
Personally, if I wasn't happy with C (well I'm not, but I'm not unhappy enough to not use it anyway, I guess), I'd rather write a compiler for a better language, with the specific problems fixed that I don't like, than degenerate myself to writing assembler manually, simply because writing a compiler once means I can have it take care of the trivialities, and let me concentrate on the interesting parts: how to actually get a given task done.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Oh and the other reason for using compilers is that they make it possible to use a different type of development cycle...
Say, if I know certain parts of some 50k lines of code modify a certain structure, and I need to change those parts to not modify it, instead creating new version or something, with a C compiler I can just make that structure "const" and it'll complain when it's handles as non-const. Then I can change the trivial parts (adding "const" in prototypes on such) leaving me with a set of compiler errors telling me exactly what are the parts of the code that actually modify the structure.
Or I want to add an extra argument to a function. So I'll just add it, and throw the result to compiler. It'll give me a list of errors where the function is called without the extra argument, and I can make all those function calls pass such an extra arguments, simply by going through the list of errors.
In kernel code especially, I'd rather have anything call a function with wrong arguments, simply because I forgot to change it. So I rely on my compiler to complain on such uses, so I can actually go and fix them.
Say, if I know certain parts of some 50k lines of code modify a certain structure, and I need to change those parts to not modify it, instead creating new version or something, with a C compiler I can just make that structure "const" and it'll complain when it's handles as non-const. Then I can change the trivial parts (adding "const" in prototypes on such) leaving me with a set of compiler errors telling me exactly what are the parts of the code that actually modify the structure.
Or I want to add an extra argument to a function. So I'll just add it, and throw the result to compiler. It'll give me a list of errors where the function is called without the extra argument, and I can make all those function calls pass such an extra arguments, simply by going through the list of errors.
In kernel code especially, I'd rather have anything call a function with wrong arguments, simply because I forgot to change it. So I rely on my compiler to complain on such uses, so I can actually go and fix them.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
I am making a full ASM OS, but this may come has a surprise, it was not by design 
. I start out with the idea to code a pascal OS, but ended up with most of the pascal code being inline assembly, I also moved from realmode to pmode which i am not the greatest fan of freepascal, So my OS is a asm + pascal OS in which i forgot to add the pascal.
But i think it was for the best, i think coding in asm, takes longer, to write the code.
But you need to do less bug fixing , why you may ask, that because with asm you do everthing your self, you put ever line of code, with high level languages, you are not in full control and alot of the code is written by others, this is quicker, but harder to get a full view of whats going on.
But there is not a best language, its more whats best for your way of coding.
. I start out with the idea to code a pascal OS, but ended up with most of the pascal code being inline assembly, I also moved from realmode to pmode which i am not the greatest fan of freepascal, So my OS is a asm + pascal OS in which i forgot to add the pascal.But i think it was for the best, i think coding in asm, takes longer, to write the code.
But you need to do less bug fixing
, why you may ask, that because with asm you do everthing your self, you put ever line of code, with high level languages, you are not in full control and alot of the code is written by others, this is quicker, but harder to get a full view of whats going on.But there is not a best language, its more whats best for your way of coding.
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
My OS is mainly based on Asm/Basic, but not entirely. The kernel is indeed 100% ASM, and so are all parts connected to it. Since the drivers are for the larger part in Basic, i doubt this meets the criterium, but then again, my os can run without a single line of HLL code. 
I like assembly because you can easily see what something does. Since register calling conventions are far easier than passing on the stack i have been avoiding C, to the point that when it pays off, basic has become more suitable for the task.
Adding to that, debugging assembly is far easier than debugging HLL
I like assembly because you can easily see what something does. Since register calling conventions are far easier than passing on the stack i have been avoiding C, to the point that when it pays off, basic has become more suitable for the task.
Adding to that, debugging assembly is far easier than debugging HLL
Not surprising since about 1.5 years ago.Dex wrote:I am making a full ASM OS, but this may come has a surprise, it was not by design
That depends on how you think as a language programmer. If you keep thinking in asm, you're going to suck doing C++ and you are going to make more errors. When I've done a few days' worth of ASM programming I have a hard time to abstract to even an object, let alone anything beyond that. After a few days of hardcore C++ programming (typelist manipulations come to mind as an example, although I have done a few less obvious bits) you're having a hard time just thinking in variables, let alone moving bytes from and to memory.But you need to do less bug fixing
Not so much by others, but by bits implicit in your code that you need to make explicit in ASM. For OS devers this holds. If you were doing application development, you could build on abstractions made by others in the form of libraries; you might do that in ASM as well. Most libraries are tailored toward structured programming languages however, leading to an insufficient amount of things you can base your ASM applications on leading to a deficit. For OS dev, you'll have to make anything you want in any case, so using ASM doesn't give you that deficit (and then still there are people making applications in full ASM - and I can't blame them).... alot of the code is written by others, this is quicker, but harder to get a full view of whats going on.
Your OS code will need to know exactly what it's doing since it's the thing that can bump against all hardware. Consider your computer a porcelain cabinet with your OS as the elephant in the middle. If, however, you know that in a higher level language or you can protect the hardware from this kind of details, you can use a higher level language just the same.
Although I agree wholeheartedly with this statement, I do have a connotation. If you can only program in one "way of coding", you need to learn at least two others before you can reasonably adjust in any nonhomogeneous environment (such as a job with more than yourself). For my work, I'm using assembly-style, imperative, object-oriented, functional and hardware-oriented during every days work. If I could only do assembly, I'd have to find a new job by next friday.But there is not a best language, its more whats best for your way of coding.
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Everything is compiled, mainly because writing an interpreter is just too much work when you can compile it already... Besides, FreeBASIC uses standard GNU tools for the job so i can happily mix assembly, C and Basic without getting too worried about things.Alboin wrote:Do you compile the basic code and then link it? Or do you have an interpreter in assembly for it? An internal scripting language for use in the OS sounds pretty cool....
Sure your right, i can program in many languages including pascal, delphi, vbasic, when i code for windows, 95% of the time i would use delphi or vbasic, but when i am coding my x86 OS or pic or arm OS, i use assembly.Candy wrote: Although I agree wholeheartedly with this statement, I do have a connotation. If you can only program in one "way of coding", you need to learn at least two others before you can reasonably adjust in any nonhomogeneous environment (such as a job with more than yourself). For my work, I'm using assembly-style, imperative, object-oriented, functional and hardware-oriented during every days work. If I could only do assembly, I'd have to find a new job by next friday.
@Alboin, DexOS has a very basic "basic interpreter" code in asm, i can send you the code if you want.
-
anon19287473
- Member
- Posts: 97
- Joined: Thu Mar 15, 2007 2:27 pm
...
MenuetOS (menuetos.net) is the perfect example of why. It is full self-hosting GUI os, w/ an IP stack and reasonably well constructed browers all in FASM. The creator rewrote parts of Linux for it, and got 10%-40% speed gains. If you are handy enough w/ ASM, it really pays off.
Re: ...
10%-40% compared to what ? Linux? Ask yourself the question is the speed gain comparable? Does it have the same architecture, functionality, etc. How many processes were running during the measurement on Linux and MenuetOS?anon19287473 wrote:MenuetOS (menuetos.net) is the perfect example of why. It is full self-hosting GUI os, w/ an IP stack and reasonably well constructed browers all in FASM. The creator rewrote parts of Linux for it, and got 10%-40% speed gains. If you are handy enough w/ ASM, it really pays off.
Author of COBOS