OSDev.org

Posted: **Wed Oct 02, 2013 1:22 am**

Hi donzniak ,

A significant portion can still be unit tested . Imagine the following situation, you are a field engineer at a customer plant due to an escalation and you made a quick fix and gave to it him, wont it be nice if he can verify the code has written ? Minix aims to be reliable alternative to Linux, small as it is , isn't it laughable that it does not contain much unit tests ?

I do not want this thread to degenerate into Linux vs Windows battle . Being a big company , Microsoft has very formal test processes ( and a dedicated test team ) and that most likely will work better than "ad hoc" testing in most open source , free projects. I am just stating my opinion based on my own professional experience.

--Thomas

Posted: **Wed Oct 02, 2013 3:45 am**

Thomas wrote:A significant portion can still be unit tested .

I agree that unit-testing is good. I just don't think it covers 100% of what has to be tested, not even close.

Posted: **Wed Oct 02, 2013 6:10 am**

Unit tests are tests performed on single components of the system. And since many components are actually glue in a large chain of dependent parts, this is difficult to do effectively as you'd have to create test code for feeding both the top end and the bottom end.

That and unit testing drivers is a pain with the actual hardware dependencies...

Posted: **Wed Oct 02, 2013 8:55 am**

I just don't think it covers 100% of what has to be tested, not even close.

Code: Select all

Unit tests are tests performed on single components of the system. And since many components are actually glue in a large chain of dependent parts, this is difficult to do effectively as you'd have to create test code for feeding both the top end and the bottom end.
That and unit testing drivers is a pain with the actual hardware dependencies...

True . unit testing scratches the surface . It is like a good sanity check and something is better than nothing. Most projects actually have none !

Posted: **Wed Oct 02, 2013 11:47 am**

Thomas wrote:True . unit testing scratches the surface . It is like a good sanity check and something is better than nothing. Most projects actually have none !

Being able to unit test individual component means it needs to be well abstracted from both below and above layers with some abstractions. Often this is not done due to performance or other reasons. Without such abstractions "mocking" necessary components to test individual parts in isolation is not possible.

Posted: **Sat Nov 02, 2013 6:32 am**

tjmonk15 wrote:They fail to utilize all hardware (in a single PC that it is installed on) at 100% efficiency.

- Monk

100% efficiency is never possible, some of the energy is used by friction and sound, heat etc. So 100% is never possible.
Physics.

Posted: **Sun Nov 03, 2013 7:49 am**

And Now to your question,
The problem with the current OSes is with their Developers,
Why?
Remember the Days of 286 and DOS? When there was no Protected Mode to provide you with 4Gigs of RAM? Remember when the software developers used to write compact, fast, and less-buggy code to over come the limitations of DOS and Intel 80286?
Where everything had to be squeezed, compressed in THAT LITTLE 1.06MB. Where DOS tried to enable the A20 Line, and access that little 64KB Section just for more RAM? Everything was so faster that time.
DOS Boot Time : 6.07 Seconds (i386)
Windows 3.11 Boot Time : 8.01 Seconds (QEMU Virtual CPU 0.13.50)
Windows 7 Boot Time : 67.08 seconds (i3-2.4Ghz)
Ubuntu Linux Boot Time : 54.03 Seconds (i3-2.4Ghz)
Look at that.
I can understand that new functionality like TCP/IP,Networking,Multiple Cores, etc. weren't implemented at that time because of the hardware limitations, But you see there is A LOT of JUNKWARE AND BLOATWARE that are installed on current OSes like Windows and I am sorry to people who use Ubuntu but it's also loaded with junkware.
The thing is now software developers are crazy with that huge 4GB RAM, and don't worry about the size of their code, once they get it working, they don't look at it much and hardly any improvements are made.
But that's not how stuff should be done.
We should still program like the MS-DOS style and assume that we have very less memory, and therefore we should write compact, and faster code. The advantage of this won't only be the application size but it would also be efficient.
Ever heard of BareMetal OS?
It has TCP/IP,Multiple Core Support,FAT16 HDD Support,Serial Ports,Has a C Library, and what else...
and what's the kernel size?

16KB

If a person comes to me and says "I made a Windows 8 Clone in C,C++ and Assembly"
And when I look at his code, and if it seems buggy,slow I'd better kick him out.
If a guy comes to me and says "I just made a simple OS"
And when I look at his code, and if it seems to be compact,fast and less-buggy I would praise him a million times.
For me the MOST important thing while developing and "OS" is that to keep the code small, compact and less-buggy and that's one of
the MOST important reasons I haven't released my OS. (Check my description)

Posted: **Sun Nov 03, 2013 3:33 pm**

No. The most important aspect of software engineering is not ultimate speed but maintainability. Assembler is fine for hobbyists but it has little place in the real world where the person who has to correct the bugs is not necessarily the person who wrote the program (or even when they are). Modern computers are plenty fast enough, and have enough resources, that they don't need to bother with the tricks that were necessary to save a few bytes or a few microseconds in the days of DOS. And they do so much more than you could with DOS.

Anyone who remembers the original IBM PCs and clones know just how much faster a modern computer is, despite all the "bloatware", GUIs and other performance killers. There's a good reason why BareMetal OS is just a minor hobbyist OS and always will be.

Posted: **Sun Nov 03, 2013 3:43 pm**

iansjack wrote:No. The most important aspect of software engineering is not ultimate speed but maintainability.

IMHO you are pretty much on the money there. Here's a quote from The Macroscope by Joël De Rosnay:

Every system has two fundamental modes of existence and behavior: maintenance and
change. The first, based on negative feedback loops, is characterized by stability. The second,
based on positive feedback loops, is characterized by growth (or decline.) The coexistence of
the two modes at the heart of an open system, constantly subject to random disturbances from
its environment, creates a series of common behavior patterns.

Without maintenance we cannot have persistance.

Posted: **Sun Nov 03, 2013 7:20 pm**

The original L4 kernel was completely done in assembler because Jochen Liedtke was eager to prove that microkernels could be fast after the questionable performance by the Mach kernel. After that a C++ version of the kernel was made that proved be fast enough compared to its assembly predecessor. The original assembler L4 kernel was therefore put on ice.

So, usually C++ has good enough performance and with all other benefits like better portability and maintainability.

If I started a kernel project today, I wouldn't even consider to write it completely in assembler.

Posted: **Sun Nov 03, 2013 7:35 pm**

iansjack wrote:Assembler is fine for hobbyists but it has little place in the real world....

That hurt me, you know?
No matter how faster computers become, ASM coders(only good ones) will offer the fastest programs for that faster hardware. So using slow software will be always slower than using faster software. I will always support people who make the bigger effort and spend more time in their work for the sake of a better product. And this apply to any human activity. I like to speak with examples. Imagine John is coding in ASM, but he's poor, imagine his rich neighbor is wanting to code too and show him how he is better coder than him(rich people often do that). The richer guy is buying a Cray supercomputer and running a script that he wrote and he program finally runs faster. This is not communistic!!!! The richer one won over the one with more talent. We always have to support talent and not richness. Excusing bad software with faster hardware is not cool, bro! If all people prefer the hardware over the effort, we all will end with computers big like houses and IE will still load slowly. I bought my first computer 5 or 6 years ago, not sure, Stage6 was still online. The first program I used was Nero. I installed the latest Nero for a guy the last month and do you know what? It was as slow/fast as it was before 5 years. No matter the newer hardware......

If I ask some engineer that works on Intel which is faster, ASM or C+-, I don't think he would say C
ASM is hard as hell, slow for coding as hell, it is painful often, but the truth is the truth- well coded ASM is faster.

I cant tell you more details, but once I had to recode a piece of C ANSI code from an official specification. And guess what! The number of lines of source code in ASM was the same as the number of lines in the source of the C ANSII(the pure code, ignoring comments). I was almost crying looking at that piece of code, it was so beautiful! Normally ASM source file is larger, but in that unique moment I achieved perfection. I have to print it some day and put it in a frame.
I'm still learning and my eyes often hurts because of ASM, but I will always like ASM. Even when I leave it and begin to use higher level languages for my hobbyist project, I will still open the libraries and change things, retouch stuff. I will not code in ASM forever, but I will love it forever.

Posted: **Mon Nov 04, 2013 1:37 am**

That hurt me, you know?

Then I'm afraid that you are reacting emotionally rather than logically to a problem that you do not really understand.

I love assembler coding, and I'm guessing that I have probably done it on far more processor architectures than you have (and x86 would probably me my least favourite). I've also earned a living in the real world writing code on a variety of machines from PCs and Macs to IBM mainframes. One thing I can tell you for sure is that no-one, in the real world, uses assembler unless they have to. You predicate your argument on the assumption that assembler is always faster than high-level code. In truth that is rarely the case; compilers nowadays are very good at producing efficient code whereas it is very easy to produce inefficient assembler code.

The first program I used was Nero. I installed the latest Nero for a guy the last month and do you know what? It was as slow/fast as it was before 5 years

Nero - a program to write CDs and DVDs. Can you guess what the bottleneck in Nero is? So can you see why it won't be any faster whether written in assembler or C. You are wasting your time producing highly optimized, but probably unmaintainable, code when the slowest part of the system is not the processing part. Nero would run just as slow on a Cray supercomputer as on an iPad.

If I ask some engineer that works on Intel which is faster, ASM or C+-, I don't think he would say C

I believe that you are wrong. Try asking such an engineer.

ASM is hard as hell, slow for coding as hell, it is painful often, but the truth is the truth- well coded ASM is faster.

The first three parts of that statement are true (and should ring a few warning bells), the last is almost always false. (If it's true then prove it rather than just assuming it must be faster.)

in that unique moment I achieved perfection

No you didn't, and it is pure hubris to suppose that you did.

Code: Select all

I will not code in ASM forever, but I will love it forever.

And there you destroy any remnant of your previous argument. If assembler is so much better than high-level languages then why will you not use it forever? You will deliberately choose a language that you think is slower, as hard to use, and no more easy for you and others to maintain? That doesn't make sense.

Posted: **Mon Nov 04, 2013 7:42 am**

I know what a bottleneck is. Nero has another video editing features. I am not talking bout the burning disk one.
I don't want to hurt you but if a compiler is producing faster code that you coding it in ASM, then you are not good at ASM.
Good coded ASM is the fastest solution always.
If so many people hate ASM and low stuff in OS development, they still can make a WebOS(http://www.silveos.com/ I can assure you, you could code an entire WEBOS and never know nothing bout bits). I don't understand someone wanting badly to make an OS and hating ASM so much at the same time.
Good coded ASM is the fastest solution always and slower to code.
So I will respect the higher language coders too, but the ones who sacrifice time to make things better will receive always more respect from me. I am sacrificing it all for my project. I could earn a good living coding applications for Windows just copying and pasting, just reading tutorials, browsing internet for solutions for the bugs of the compiler. But in the end I will end up working and living for windows. If someday windows just cancels Visual studio project, I will have nothing to do, because I would learned the minimal and earned the maximal. And you cant compare the creativity of using Visual Basic and using ASM. I am the nearest possible I could be to rule in my system using ASM. There are almost infinite possibilities to code, I'm limited only by hardware and my knowledge.
I don't wish to offend you, but using ASM requires more thinking. It's not like declaring 5000 variables in the header of your C++ source file and going forward. You have to deal with limited resources in order to make a fast ASM code. I am shown to solve problems with almost no resources. In the near future when the first quantum computers have only 3 registers to manage, I will be there trained how to write programs for limited systems, and high level programmers who hate ASM will be just waiting for people like me to produce the first compiler so they can use what I will be using already.
And yes, I decided to use higher languages, maybe C syntax, when I finish the current project. Because world is pushing me for productivity. I will use the syntax of C ANSI to not lose coherency with the rest of the world, but the compiler, I will code it in ASM from the zero-scratch. Next I will code interpreter for some standardized script syntax too. But I will always love and respect ASM. I would never say C s faster than ASM, I would say C is a compromise between productivity and speed.

Again: http://www.silveos.com/ it is nothing bad to code a WebOS. I think it's bad to like a real life OS and blame ASM constantly. That hurts me!

Posted: **Mon Nov 04, 2013 9:11 am**

Hi,

newanabe wrote:I don't want to hurt you but if a compiler is producing faster code that you coding it in ASM, then you are not good at ASM.

Or you are using a decent, modern, optimising compiler.

newanabe wrote:If so many people hate ASM and low stuff in OS development, they still can make a WebOS(http://www.silveos.com/ I can assure you, you could code an entire WEBOS and never know nothing bout bits).

Not everyone uses HLL's because they 'hate' ASM. They may just be in the habbit of using the appropriate tools for the job.

newanabe wrote:I don't understand someone wanting badly to make an OS and hating ASM so much at the same time.

iansjack wrote:I love assembler coding

?

newanabe wrote:Good coded ASM is the fastest solution always and slower to code.

Lucky that optimising compilers generally produce good ASM, then.

newanabe wrote:If someday windows just cancels Visual studio project, I will have nothing to do, because I would learned the minimal and earned the maximal. And you cant compare the creativity of using Visual Basic and using ASM.

Depends if they're a code monkey or a well educated professional programmer.

newanabe wrote:I am the nearest possible I could be to rule in my system using ASM. There are almost infinite possibilities to code, I'm limited only by hardware and my knowledge.

This is no different in C. You can quite easily incorporate ASM in to a project where it's the most appropriate tool to use.

newanabe wrote:I don't wish to offend you, but using ASM requires more thinking. It's not like declaring 5000 variables in the header of your C++ source file and going forward. You have to deal with limited resources in order to make a fast ASM code. I am shown to solve problems with almost no resources.

In a system with 'almost no resources', perhaps ASM is the most suitable tool for the job. We'd have to know more about the system in question and the problem that you solved. Also, if you declare 5000 (presumably global?) variables in the header of your C++ source file, you need to look at redesigning your project.

newanabe wrote:In the near future when the first quantum computers have only 3 registers to manage, I will be there trained how to write programs for limited systems, and high level programmers who hate ASM will be just waiting for people like me to produce the first compiler so they can use what I will be using already.

Too many hypotheticals.

newanabe wrote: Again: http://www.silveos.com/ it is nothing bad to code a WebOS. I think it's bad to like a real life OS and blame ASM constantly. That hurts me!

This sounds like developing an emotional attachment to a language. It's great to love what you do, but if you're in a scientific / technological profession you need to be able to take criticism without getting offended - otherwise you will spend your entire career being offended.

Cheers,
Adam

Posted: **Mon Nov 04, 2013 9:30 am**

AJ wrote: This sounds like developing an emotional attachment to a language. It's great to love what you do, but if you're in a scientific / technological profession you need to be able to take criticism without getting offended - otherwise you will spend your entire career being offended.

Hi!

That's correct! I always try to avoid pointless arguing, but I'm sometimes too lonely. In company I am speaking bout coding and people run from me. So when lonely, and I see something upsets me, I start that pointless arguing, because nothing will change even after 5 pages of replies.
Have a nice day! I will try to avoid similar topics, until too lonely to handle again

see ya!
newanabe

OSDev.org

Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes

Re: Problems with existing OSes