Thank you Casper. In a nutshell ! ! I only wish I could have put it so succinctly. The problem with ros at the moment (and it is not life threatening) is: There is no space set aside for private discussion, but which, at the same times allows for returning to the ros-general thread again. Because of that (design failure not code failure), we all stay in the ros-general public space and argue over the top of one another. Sometimes it seems like the floor of the NYSE, where people must waive and shout to get attention to their particular issue. Good fun for some but agony for others. Regards and rosuccess Justin
---- Casper Hornstrup ch@csh-consult.dk wrote:
You have to know when to use it. I think we do okay in that area. We have assembler optimized versions of string functions which are often executed during operation, but we also have C versions of these functions to make ReactOS easier to port to new architectures. We have assembler code for very low-level code which would be impossible to do in C. I believe there should be a minimum of assembly used to increase maintainability/portability and when used, it should be because there is a major speed difference during _normal operation_ of the OS. If a function which is called only once during startup of the OS could be made 1ns faster using assembly, then it doesn't really make ReactOS feel faster to the user even though running the function 10000 times in a loop might show a 1000% average speed increase. If the function was run 1000 times a second during normal operation then the user might feel a difference. There are other ways to make ReactOS faster than resorting to assembly. You could use better algorithms for instance.
Casper
-----Original Message----- From: ros-general-bounces@reactos.org [mailto:ros-general-bounces@reactos.org] On Behalf Of Kevin Lawton Sent: 18. oktober 2005 10:30 To: ReactOS General List Subject: RE: [ros-general] New to ReactOS
Yeah, okay, but . . . With C being a 'higher level' language than assembler it will always be easier for a group of humans to work on a project in. You could take this further and use something like Java, though not for an op-system kernel as Java programs need something below them to run the run-time virtual machine. C is a good language for writing an op system in because that is why it was designed (by Kerningham and Ritchie - their book on C is still the best work of its kind). It was created to write the Unix op system in and the combination of high and low-level features will always make it ideal for such a task. In terms of generating nice tight machine code when compiled, C is probably the best high-level language in this respect. Modern computers are so enormously powerful that most projects feel that it is unnecessary to use assembler for the extreme efficiency it offers - C is more than 'good enough'. But, when projects ARE written for modern machines using assembler we then start to see just how fast things can go. We might feel that the 'average' PC is plenty fast enough performing day-to-day tasks with an op system written in C and applications in Java or VB, and it probably is, but give it a chance to run software written in good assembler and you can get quite a surprise. Even if we think we can spare it, those high-level language programs (incl op system) can perform nothing like the blistering performance you can get from really good assembler code. You also find that because assembler programming is so 'direct' then the resulting machine code tends to be far more compact than that generated from other languages. Smaller programs (op systems included) use less room on disk, load faster into a smaller memory space and tend to have shorter execution paths. It is all fine and dandy that ReactOS will be a working 'clone' of Windows but Windows is often criticised for being large and slow. What if ReactOS could achieve full Windows compatibility while being much smaller and faster ? Kevin.
ros-general mailing list ros-general@reactos.org http://www.reactos.org/mailman/listinfo/ros-general
You can come by IRC for more or less private discussions.
http://www.reactos.org/en/community_irc.html
Casper
-----Original Message----- From: jwalsh@bigpond.net.au [mailto:jwalsh@bigpond.net.au] Sent: 18. oktober 2005 20:51 To: ReactOS General List Cc: Casper Hornstrup Subject: RE: [ros-general] New to ReactOS
Thank you Casper. In a nutshell ! ! I only wish I could have put it so succinctly. The problem with ros at the moment (and it is not life threatening) is: There is no space set aside for private discussion, but which, at the same times allows for returning to the ros-general thread again. Because of that (design failure not code failure), we all stay in the ros-general public space and argue over the top of one another. Sometimes it seems like the floor of the NYSE, where people must waive and shout to get attention to their particular issue. Good fun for some but agony for others. Regards and rosuccess Justin
---- Casper Hornstrup ch@csh-consult.dk wrote:
You have to know when to use it. I think we do okay in that area. We have assembler optimized versions of string functions which are often executed during operation, but we also have C versions of these functions to make ReactOS easier to port to new architectures. We have assembler code for very low-level code which would be impossible to do in C. I believe there should be a minimum of assembly used to increase maintainability/portability and when used, it should be because there is a major speed difference during _normal operation_ of the OS. If a function which is called only once during startup of the OS could be made 1ns faster using assembly, then it doesn't really make ReactOS feel faster to the user even though running the function 10000 times in a loop might show a 1000% average speed increase. If the function was run 1000 times a second during normal operation then the user might feel a difference. There are other ways to make ReactOS faster than resorting to assembly. You could use better algorithms for instance.
Casper
-----Original Message----- From: ros-general-bounces@reactos.org [mailto:ros-general-bounces@reactos.org] On Behalf Of
Kevin
Lawton Sent: 18. oktober 2005 10:30 To: ReactOS General List Subject: RE: [ros-general] New to ReactOS
Yeah, okay, but . . . With C being a 'higher level' language than assembler it will always be easier for a group of humans to work on a project in. You could take this further and use something like Java, though not for an op-system kernel as Java programs need something below them to run the run-time virtual machine. C is a good language for writing an op system in because that is why it was designed (by Kerningham and Ritchie - their book on C is still the best work of its kind). It was created to write the Unix op system in and the combination of high and low-level features will always make it ideal for such a task. In terms of generating nice tight machine code when compiled, C is probably the best high-level language in this respect. Modern computers are so enormously powerful that most projects feel that it is unnecessary to use assembler for the extreme efficiency it offers - C is more than 'good enough'. But, when projects ARE written for modern machines using assembler we then start to see just how fast things can go. We might feel that the 'average' PC is plenty fast enough performing day-to-day tasks with an op system written in C and applications in Java or VB, and it probably is, but give it a chance to run software written in good assembler and you can get quite a surprise. Even if we think we can spare it, those high-level language programs (incl op system) can perform nothing like the blistering performance you can get from really good assembler code. You also find that because assembler programming is so 'direct' then the resulting machine code tends to be far more compact than that generated from other languages. Smaller programs (op systems included) use less room on disk, load faster into a smaller memory space and tend to have shorter execution paths. It is all fine and dandy that ReactOS will be a working 'clone' of Windows but Windows is often criticised for being large and slow. What if ReactOS could achieve full Windows compatibility while being much smaller and faster ? Kevin.
ros-general mailing list ros-general@reactos.org http://www.reactos.org/mailman/listinfo/ros-general
-
Casper Hornstrup -
jwalsh＠bigpond.net.au