Ville Turjanmaa creator of the pretty well known Pure ASM OS, MenuetOS has recently spent some time away from the project working on a 64bit version of MenuetOS.
64bit MenuetOS In the Works
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
writing GUI stuff in assembler… does it make any sense? 😉
writing GUI stuff in assembler… does it make any sense? 😉
Depends on the Operating System you’re using. And if you’re programming on MenuetOS it’s really easy.
If you build yourself a good macro toolkit and ASM library, it’s not much different than programming in a high-level language. Except that there’s no question marks about the quality of code the compiler is producing, and there’s way less overhead code.
GEOS was written pretty much entirely in 8086 assembly. It really wasn’t bad at all to code for. In fact, I’d go as far as to say that GUI coding in assembly for GEOS is far easier to do than coding for Win32 or MFC in C or C++.
As Innominandum said, the trick is having a good set of macros, and making sure that your core libraries are well designed.
Of course, writing everything in assembly really hurts when you have to make major changes. GEOS never made it to 32 bit due to the huge volume of code to change. Most of the UI widgets were limited to 256 colors, as it would’ve taken a huge refactoring of the UI code to free up another register every place colors were used.
assembler is a good feature for low-level code but it makes code hardly portable to another architecture (but maybe you don’t want that anyway) – but fact is, that compilers often create more optimized code (maybe not the cleanest)..
but i like the idea of an ASM OS
> Most of the UI widgets were limited to 256 colors, as it would’ve taken a huge refactoring of the UI code to free up another register every place colors were used.
If you have the right macro toolkit, things like this can be avoided too. I implemented “types” and “structures” in my macro library to avoid this situation.
> low-level code but it makes code hardly portable to another architecture
While it’s true it’s may take a bit of work to port your software to a different hardware architecture, it’s pretty easy to make your software portable for different OS architectures.
> but fact is, that compilers often create more optimized code (maybe not the cleanest)..
That’s not a fact. In is fact that’s completely wrong. It’s IMPOSSIBLE for a compiler to come ANYWHERE close to a reasonably good ASM programmer in terms of legibility or efficiency.
I’ve seen the output from modern compilers and it’s atrocious.
I’ve seen the output from modern compilers and it’s atrocious.
Did you use -O3 (or equivalent)?
Just to add to this. If you’re using a compiler you have to wait until you (Or more likely the compiler writers) decide to add support for a new chips feature set. Then you have to wait for that support to be debugged. Then finally, if you’re lucky, there might be some optimisation for those features. An ASM writer doesn’t, the compiler is in effect their brain so if it’s in a processor manual somewhere it’s immediately useful.
That’s not to say everyone should suddenly drop C and learn ASM. Just be aware that simply because your compiler has a flag for a specific architecture doesn’t actually mean there’s a hell of a lot of architecture specific optimisation/instruction scheduling going on.
I love how small asm project .exe files are .
Small and cuddly.
Much compiler optimisation comes in the form of targetting cache sizes, etc. This isn’t something that often performed by ASM programmers, so it is possible for a compiler for produce better run time performing code. (-O3 will frequently make things worse, by generating larger run times that take longer to be executed)
In general, however, ASM will provide faster run-time performance than C, since the programmer is forced to adapt their problem much more to the architecture involved, which is essentially the whole point of optimisation n e way. ie C + gcc = coding a solution in one form, then altering it, while ASM means coding it in the form required to begin with.
Also, don’t forget that hardly anyone uses asm unless it’s supposed to be an highly optimized code.
as an example, i code mostly in delphi, but if i need to make something run fast (like long calculations and memory moving) asm is the way to do it.
I guess that someone coding in assembler will always try to code for the best performance possible (even targetting cache sizes, and different instruction sets).
Agreed. Anyone else agree?
i agree
me too
>> Most of the UI widgets were limited to 256 colors, as it would’ve taken a huge refactoring of the UI code to free up another register every place colors were used.
>If you have the right macro toolkit, things like this can be avoided too. I implemented “types” and “structures” in my macro library to avoid this situation.
Of course, things like that can be avoided if planned for. The assembler used for GEOS had support for structs, enums, local variables, some limited typing (probably about as good as you could get in asm, but that’s not saying much), and really just about all the fluff a language like C has.
In this particular case, considering the OS was targetted to be a multitasking GUI capable of running on an XT, the limiting to 256 colors was a deliberate design choice, as 16 color displays weren’t even that widespread yet. Having that extra register free meant a lot, considering x86 only has 8 registers.
Anyway, no matter how could your asm design is, you’re eventually going to hit a point where you need a major overhaul of the code to implement new features. In a high level language there is no penalty to suddenly deciding you need to add another variable to a function. In an optimized assembly function, one more variable could force you to rewrite the entire section.
One good thing about writing a large project in assembly is it forces you to have good tools. It’s practically impossible to pull the project off successfully without a good development setup. The higher level your language is, the more you can get away with a crappy setup.
ASM is amazing =] and i realy like MenuetOS…
I myself wrote some programs in asm – like – AsmPad =]
3584 bytes