flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > criticism

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
mike.dld



Joined: 03 Oct 2003
Posts: 235
Location: Belarus, Minsk
mike.dld
Some news from here. Just about what russian team is working on Wink Not a debate continuation.
Pj wrote:
I need to tell it how much RAM I have
Not that in russian distro and latest official distros.
Pj wrote:
each icon on the desktop is an individual process
Mario79 working now on that (trying to pack ICON into 1 process with some number of threads)
Pj wrote:
the line drawing code draws awful lines (a good routine drawing from 0,0 to 16,2 would put 4 pixels on line 0, 8 pixels on line 1, and 4 pixels on line 2)
You're right here, take a look at this screenshot (from above is native MenuetOS drawing routine, from below is what my MenuetOS driver draws):
Image
Post 24 Jan 2005, 22:34
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
daneel



Joined: 19 May 2004
Posts: 56
daneel
What about a UNICODE font ?
Post 25 Jan 2005, 14:20
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2145
Location: Estonia
Madis731
It's being worked on - just like browser
Post 25 Jan 2005, 15:38
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
luka666



Joined: 17 Aug 2004
Posts: 22
luka666
you can get unicode here . somebody has to include it into the kernel....
Post 25 Jan 2005, 15:44
View user's profile Send private message Reply with quote
Adam Kachwalla



Joined: 01 Apr 2006
Posts: 150
Adam Kachwalla
Well... MenuetOS was written in ASM ONLY: All the others use C. ASM is a little harder to work with, but the result is powerful. MenuetOS fits on a floppy, and another OS with all the features, written in C, would be bloated up.
Post 25 Apr 2006, 00:01
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

MenuetOS fits on a floppy, and another OS with all the features, written in C, would be bloated up.

And what exactly do you base that opinion on? Smile
Post 25 Apr 2006, 10:18
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
f0dder wrote:
And what exactly do you base that opinion on? Smile

C programs aren't necessary that bloated up, since I code some of my testing programs to check my ideas if they work. What makes C bloated is the damn standard library -- printf for example is overbloated in implementation (I checked it), and 90% of the time, it introduces features you don't even use!

What I REALLY love about asm is that it can do nice tricks, and you can understand low-level internals with it (it gives more knowledge and experience about the computer than C). For me, even if asm saves off 15 bytes more than the C version, I still choose it (well, there may be some other 'situations', but I'm talking generally). Smile And low-level tricks and algorithms are a much interesting intellectual challenge, and i like that Smile

and by the way -- C was designed to be a standard. That is, it doesn't expose computer-specific features. Wink
Post 25 Apr 2006, 14:30
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

printf for example is overbloated in implementation (I checked it), and 90% of the time, it introduces features you don't even use!

That's a problem with how printf works - format strings and all. It's a bit hard knowing at compile/link time which features will be used, so it's all linked in. If you don't need the complexity of printf, use puts instead. And, well, the libc isn't too bad really... a hello.exe with no tricks and msvc libc is 28kb. You'll have to go many CPU architectures back before this would pose a serious problem. And of course, the libc is a one-time "bloat" - once you actually start using the libc, the amount of wasted bytes go down drastically. If you don't use the libc, well, the don't include it in your programs. Or, use a libc replacement... with Jibz' WCRT, the simple hello.exe goes down to 3.072 bytes.

So much for bloat Smile

OF course the language to choose depends on your needs and what you feel good about. Skipping C/C++ because of "bloat" is a silly misinformed choice, though.
Post 25 Apr 2006, 17:10
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
There are so many languages to work with, it's almost ridiculous. Choose wisely, but don't limit yourself to just one or two! Whatever makes you comfortable, use it. But, strive to write small, fast, portable, useful, clean, commented (or at least easily-licensed) code. Oh, and have fun! Otherwise, why waste your time? Very Happy
Post 26 Apr 2006, 22:26
View user's profile Send private message Visit poster's website Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
gunblade
f0dder, those hello world examples are still big.. even with the shrunk libc you were talking about, 3kb for a hello world is quite big, even for windows.
Yes, it doesnt seem like a lot, its only 3kb, but if your trying to pack as much functionality into an OS, and that OS runs from a floppy, size matters. Not only that, it will means less memory usage.

Another thing with C; the compiler always creates extraneous instructions. A compiler isnt a human, it doesnt know whether a certain register actually needs to be stored or not. Therefore it might push a register when it doesnt need to. Compile a program into assembly and its easy to see how many unneeded operations there are.

Oh, and most C compilers will take up much more space than fasm.

But it could be worse.. It could be Ada Laughing
(Sorry to anyone who likes ada, but im being forced to use it for my course in university, so i have a bad opinion about it. Next year you'll hear me complain about Java Wink)

One final comment. It's a shame that menuet32 died off (as far as i can tell). It was designed as an OS which is suppose to support old hardware (which is why they didnt implement SSE and such), but now only the 64bit version is still in development, its a shame Sad (although i seen the screenshots of the latest menuet64, and its looking really nice. Well done)
Post 27 Apr 2006, 12:01
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

Yes, it doesnt seem like a lot, its only 3kb, but if your trying to pack as much functionality into an OS, and that OS runs from a floppy, size matters. Not only that, it will means less memory usage.

If you're writing a OS you're not including libc... and as for 3kb, that's *including* parts libc which gives you quite a lot of code to play with. Without libc, with proper sections and 512byte alignment, no merging tricks, no dirtyness of any kind, you get a 2kb executable. If you think this is "bad" or "bloat", you need to get a life Smile

Quote:

Compile a program into assembly and its easy to see how many unneeded operations there are.

If you use a retarded compiler, or turn optimizations off when compiling, the code will be pretty bad. But use a modern compiler, especially one with global optimizations and link-time code generation, and the results are pretty good. Sure, you can often handwrite things better, but most of the time: it's not worth the effort.
Post 27 Apr 2006, 12:22
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
Gunblade,

SolarOS is still under active development, it is 32bits and works on older computers Wink

http://www.oby.ro/
Post 27 Apr 2006, 16:38
View user's profile Send private message Visit poster's website Reply with quote
profkid13



Joined: 21 Aug 2003
Posts: 112
profkid13
active development?
last update was on 2005-03-01 !
Post 29 Apr 2006, 17:48
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 383
Location: Finland
okasvi
profkid13 wrote:
active development?
last update was on 2005-03-01 !


for some ppl quality comes before quantity


Quote:
2006-03-15 - Work in progress:

New things:

* Added Bresenham Circle and Line demo application
* Added "WatchDog" on/off option
* Added CD-ROM ISO 9660 filesystem and browse
* Added queued non-blocking ATA HDD read
* Added HDD queue throttle for CPU utilization
* Added USB initial drivers
* Added ATPI driver
* improved text viewer speed and parse algorithm
* list and use all VESA available modes (boot advanced menus)

Working on:

* API_File_Open()
* int 13 extensions for HDD booting over 8G
* i810, 815 GART video drivers (Eugen)
* USB drivers
* USB stick booting

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 29 Apr 2006, 22:02
View user's profile Send private message MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
f0dder wrote:
OF course the language to choose depends on your needs and what you feel good about. Skipping C/C++ because of "bloat" is a silly misinformed choice, though.
Sure, sometimes I code in C and I don't use the standard library much. What I don't like about C is that it doesn't has so much flexibility -- and it's sometimes abstracted, I don't like to be abstracted. But it's also my HLL of choice (of course, asm is a LLL, but among HLLs I chose C since it's the lowest level HLL). Sure, C-- is a hybrid between HLL and LLL too Wink

And besides: C has bloat. If you're talking about BIG bloat, then you're probably right that it doesn't insert any bloat. But I'm from the view "small things should not be taken lightly". And I'm NOT the guy who thinks "better performance" means "wasting resources". From my view, faster and more powerful computers are not an excuse for me to get lazy and write junk code. We're not in 1979, but that doesn't mean today that JUNK is acceptable just because computers are faster.
(ok, don't get me wrong, C is my choice HLL, but I wasn't even complaining about C, I was complaining about phrases like "we're not in 1979, let's get lazy and waste resources")

Plus, C++ is VERY bloated. That's NOT because the compiler is stupid or because of the standard library, that's because of HOW YOU DESIGN your code. If you design it with objects, the compiler will optimize objects, but the design will remain unchanged. Therefore, I've seen a lot of projects that could've been designed without objects to improve performance.

So in HLLs, it's not a question of how powerful the compiler is, it's a question of how you design your code. That's what makes hand-written assembly better -- when you design in asm, you usually think in every low-level possible form, and design it differently than you would with a HLL. Trust me, I've had experience. I don't like very abstracted HLLs like C++.


f0dder wrote:
Sure, you can often handwrite things better, but most of the time: it's not worth the effort.
Hey, I'm not doing it for profit (aka money), I'm doing it because I appreciate small things (like only byte). And I also like intellectual challenges -- asm is not so abstracted and allows you to think much more. Sure, I don't recommend implementing an algorithm and improving it unless you tried different methods and algorithms. For example, the HLL stage (choosing different algorithms) should be done first -- I usually test my algorithms in C, and only when I agree to choose one, I implement it in asm (if the project is in asm) and then improve it in low-level.

"you can often handwrite"...
why often? I'd say always. Like I said, it's not a matter of how powerful the optimizing compiler optimizes your algorithms and design, it's a matter of how you design your code -- in asm, you usually design it differently than in HLLs. Of course, non-experts won't probably design in asm better, but by practice they will in time. No matter how powerful the compiler is, it will still optimize YOUR design/algorithms. In asm, you have different designs. No matter how hard you improve something, there will be a better solution, even if it demands a TOTAL rewrite of the whole design's structure.

besides, the argument "optimizing compilers will probably do a better job than handwrite" is ridiculous. Just imagine yourself looking at the output of a compiler and improve that. So much for that argument Wink
Post 01 May 2006, 11:29
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Most of the time, I code to "get things done". Not necessarily for profit, but still because I have a need for a tool. I am for good performance (and even for small size, silly as I am Razz), but I really can't be arsed to handwrite things in assembly unless there are some very tangible benefits from doing so.

The slowest test computer I have is a 350MHz Pentium2 with MMX and 64meg ram, and I try to make sure all my stuff runs reasonably on that machine (this means "runs well" in most cases, unless there's some heavy calculations involved). I think it's fair enough to have a machine like that as minimum specs in 2006.

On such a machine, a ~100kb executable is *nothing*. Even on a puny 4gig harddrive, such an executable is 0.0024% of the total disk space, and thus "bloat" seems like a wrong word Smile


Quote:

Plus, C++ is VERY bloated. That's NOT because the compiler is stupid or because of the standard library, that's because of HOW YOU DESIGN your code.


That certainly depends on HOW you design your code. My bin2o (binary file -> ms coff) program is written in C++ with classes and everything, but the executable is still only 4kb. Yes, it could be done smaller in assembly etc yadda yadda, but what's the point? Even when dealing with full class hierarchies, your don't necessarily get explosive code bloat if you know what you're doing.

I put stability and maintanability over size and efficiency... but I still value size and efficiency a lot. I just find some statements on "bloat" to be very ludicruous.

Quote:

No matter how hard you improve something, there will be a better solution, even if it demands a TOTAL rewrite of the whole design's structure.


Sometimes theres one optimal solution, and sometimes the compiler will choose that. Other times, the one optimal (or few near-optimal) solutions will only be marginally better than a "good" solution, but will require an disproportinonate amount of time to design. Even though most of my programs are done for fun, I still value my time.

But even if I've grown "old and lazy" and mostly use assembly "where there's a need", I also sometimes write assembly just for fun - it's just not my main language since I left the 32bit DOS days and my 486.
Post 01 May 2006, 12:29
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
f0dder wrote:
Most of the time, I code to "get things done". Not necessarily for profit, but still because I have a need for a tool. I am for good performance (and even for small size, silly as I am Razz), but I really can't be arsed to handwrite things in assembly unless there are some very tangible benefits from doing so.
Sure, I use C too sometimes when I make some automated tools. That's because it gets really annoying when i have to do things over and over again (which have nothing to do with coding, btw). A good example would be a sin/cos table generator Smile

f0dder wrote:
The slowest test computer I have is a 350MHz Pentium2 with MMX and 64meg ram, and I try to make sure all my stuff runs reasonably on that machine (this means "runs well" in most cases, unless there's some heavy calculations involved). I think it's fair enough to have a machine like that as minimum specs in 2006.
My point was not necessary that it "runs well". Of course some of my programs would run well on a 386 too. My point was more of "appreciation" -- I appreciate the low level things, no matter if it's noticeable or not. Sure, that's only for some projects, I'm not doing it for EVERY project of course Smile. But the fact was that I appreciate even non-noticeable things, no matter of the power of the CPU, because that things are STILL done internally, just that with a 3Ghz processor they are done faster than on a 1Mhz one, but they are STILL done inside. And my point was that I appreciate them (for some of my projects, of course, not all of them). I was merely explaining my view, I have nothing against your opinions as well. Wink

f0dder wrote:
On such a machine, a ~100kb executable is *nothing*. Even on a puny 4gig harddrive, such an executable is 0.0024% of the total disk space, and thus "bloat" seems like a wrong word Smile
regarding my previos paragraph, 100kb is *something*, only that it isn't noticeable by us humans (well, maybe not all of us). But, the truth inside is that, it still takes some bytes, around 100kb, even if it isn't noticeable. And I dunno why I feel somewhat close to such internals. It's just my opinion anyway Smile


f0dder wrote:
Sometimes theres one optimal solution, and sometimes the compiler will choose that. Other times, the one optimal (or few near-optimal) solutions will only be marginally better than a "good" solution, but will require an disproportinonate amount of time to design. Even though most of my programs are done for fun, I still value my time.
Exactly what I meant Very Happy
Asm takes more time, but the argument "optimizing compilers will probably do a better job than handwrite" is false. My saying was that "redesigning" your code so it is improved will always be possible, but it will certainly require more time to do it. What I wanted to say was that it matters how you design your code, and in asm you usually design it better (if you know asm well, of course). But that doesn't mean it doesn't take more time.

f0dder wrote:
But even if I've grown "old and lazy" and mostly use assembly "where there's a need", I also sometimes write assembly just for fun - it's just not my main language since I left the 32bit DOS days and my 486.
Nah, you're far from being as "old and lazy" as other people I know Very Happy
besides, I'm also a bit lazy sometimes, especially for annoying tools (which I don't release anyway, since they're very specific to my machine and customizations, etc.. and there's no point. I just write them because I'm annoyed sometimes from doing the same thing again and again).

Lazyness is a human flaw and we all have it Wink
Post 01 May 2006, 13:08
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

Asm takes more time, but the argument "optimizing compilers will probably do a better job than handwrite" is false.


That depends, really Smile
It takes some experience to beat a decent compiler, and usually you won't "super-hand-optimize" your entire program. From the assembly code I see a lot of people writing (here, asmcommunity, masmforum, newsgroups), even mediocre C code would end up with better machine code.

That's the observation I base the above statement on.

And well, I do appreciate internals - one day I just realized that I tended to get lost in the details instead of getting work done. So when writing something like http://fSekrit.donationcoder.com , I was (relatively) lazy - but the end result is still pretty tiny, especially compared to the other similar products around (like Steganos LockNote).
Post 01 May 2006, 13:24
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
f0dder wrote:
That depends, really Smile
It takes some experience to beat a decent compiler, and usually you won't "super-hand-optimize" your entire program. From the assembly code I see a lot of people writing (here, asmcommunity, masmforum, newsgroups), even mediocre C code would end up with better machine code.
But you can always cheat and look at the output of the C compiler, and hand improve that Wink so you're always gonna beat it this way
Post 01 May 2006, 13:40
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
True - that does lower the barrier a bit. (But there's still those *rare* times where the compiler generates optimal output Smile).

I find that looking at compiler output often leads to sub-optimal code, because you lock yourself into the compiler way of thinking...
Post 01 May 2006, 15:02
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.