Modern C compilers typically generate code that is as fast or faster than what a person could do it really doesn't make sense.
Correction: Modern C compilers typically generate code that is as fast or faster than what a person who doesn't know assembly language could write. Modern C compilers never generate code that is as fast as an experienced assembly language coder would write, except in trivial, easy cases where what the programmer is trying to do is simple enough that the compiler can understand it. AI still being a distant gleem in researchers' eyes, compilers lack the necessary understanding of what the programmer is actually attempting to do that they need to be truly effective optimizers.
I've seen a lot of disassembled code since I first learned assembly 16 years ago. Once in a while, I've seen trivial bits of code translated as fast as possible. Mostly, I've seen code that I could have written faster in assembly. Never, not even once, have I seen code that was faster than I would have produced myself.
The critical weakness that prevents C code from ever being as fast as assembly language code is the fact that the compiler doesn't know what you're doing. If I write a program in assembly language from the start, it's not going to look or work like a C program written to do the same thing. Not surprisingly then, since the best a C compiler can do is translate your C code into assembly code, it won't be as fast. In order to be as fast, the compiler would need to examine your C program, understand what it's supposed to do, and then write essentially from scratch its own assembly code to do the same thing, paying no attention to how your C code went about it but simply to what the end result would be. At this point, you're not feeding the C compiler code, you're feeding it a specificiation for what a program should do given these inputs and outputs.
Once compilers are capable of doing that, you won't need to write C code to begin with. You'll be able to simply tell the compiler what you want and let it do all the coding. But until this becomes the way compilers work, it will not be possible for a compiler to generate code as small and as fast as an experienced assembly language programmer.
--
-- "Convictions are more dangerous enemies of truth than lies."
Is it just me, or is there a lot of hype over an OS that doesn't seem to be much more then a real time executive? It seems to get its speed more from not having any protection, or abstraction layer then being in asm. Having worked with stripped down OS's/Execs for years, I'll tell you its better to just add more machine. They have their place on smaller micros like the motorola 68xx and intel 8051 families, but not the IA-32 series.
Merry Christmas, and in defense of this operating system, I would like to say that we are creating a developers environment..... We are not looking towards creating the most portable or even something for regular users... The V2 Labs guys (who created this in the first place) created this with a goal of maximizing multimedia. This operating system boots in about 1 second. So you can eventually have this sucker being your mp3 player in your car, or anything else and guess what... It will boot in 1 second!
Why would anyone want to work with this? I work with it because there is a lot needed to make this a fully functional operating system. I don't know about most of you, but I wasn't able to help contribute to the base of any other operating system, and the experience for me is a good one. It may not turn out to be everything we want, but I am learning a lot about shells and operating systems.
Speaking of shells, if you want to get a shell for V2 OS, go to v2dash.hypermart.net It is up to version 0.007a (codename Golden Eye). It is open source, so if you want to help in the coding of a shell (unix style), now is a great opertunity..... Last of all Merry Christmas, Happy Chanukkah, and have a good day if you don't observe either of these holidays!
V2 is a _demo coder's OS_.
by
Martin+Ling
·
· Score: 3
Excuse me, but I come along here, see this being slagged off, and feel I need to apply the cluebat. This isn't trolling or flamebait, it's just me trying to clarify what the point of this is and what it isn't.
For one thing, it's been out less than a month. I've never seen development pick up so quickly on anything. Linux 0.01 was released in 1991, that was eight years ago. And there are people trying to compare.
Contrary to what most Linux advocates would seem to tell you, different OS's are good for different things.
V2 is not designed to be desperately stable, and certainly not portable. 100% assembler = 100% CPU power. This is a demo coder's OS, and damn cool it's going to be too. A lot of the old demoscene is waking up to this, and I've no doubt some very good stuff is going to show up soon.
But let's not take it for what it isn't. Yes, maybe this is a toy OS. Don't you guys have a sense of fun?:)
Well, ASM in general isn't (IA-32... well, Intel screwed up. Learn something easier, say MIPS or 68K or HC11 or PPC or StrongARM).
Also, C compiler optimization is a limit of knowledge of the optimization programmers (i.e., how well do they know the architecture, and what language construct modifications can reduce the architecture instructions [taking advantage of instructions that do more than one thing at the same time {integer division often returns both the quotient and the remainder - save several hundred cycles by storing the remainder if its used later}]). While *in general* a C compiler can probably generate pretty good assembly, nothing does beat handcrafted ASM (with proper comments), rather than looking at the compiler output before assembly.
Likewise, from the Art of Assembly (book available online, don't have URL) by Randall Hyde, it's possible to create lousy assembly that runs slower than its C counterpart, but it's also possible to make asm much faster than a C compiler can ever generate. Plus, if you know the processor well, you can take advantage of architectural efficiencies (like helping branch prediction) by reordering asm code without having to look too convoluted. Additionally, you get some raw power that is difficult to do with C (bit twiddling is much easier with asm than C, plus, it's easy to initialize a large data memory allocation in asm to some specific value (initialize pointer. Write value using largest processor can do, using a post-increment addressing mode. Is value of pointer > end of data block [which can be of various types]? If so, end, else repeat). Of course, this has serious alignment issues.
Slashdot Mirror
Correction: Modern C compilers typically generate code that is as fast or faster than what a person who doesn't know assembly language could write. Modern C compilers never generate code that is as fast as an experienced assembly language coder would write, except in trivial, easy cases where what the programmer is trying to do is simple enough that the compiler can understand it. AI still being a distant gleem in researchers' eyes, compilers lack the necessary understanding of what the programmer is actually attempting to do that they need to be truly effective optimizers.
I've seen a lot of disassembled code since I first learned assembly 16 years ago. Once in a while, I've seen trivial bits of code translated as fast as possible. Mostly, I've seen code that I could have written faster in assembly. Never, not even once, have I seen code that was faster than I would have produced myself.
The critical weakness that prevents C code from ever being as fast as assembly language code is the fact that the compiler doesn't know what you're doing. If I write a program in assembly language from the start, it's not going to look or work like a C program written to do the same thing. Not surprisingly then, since the best a C compiler can do is translate your C code into assembly code, it won't be as fast. In order to be as fast, the compiler would need to examine your C program, understand what it's supposed to do, and then write essentially from scratch its own assembly code to do the same thing, paying no attention to how your C code went about it but simply to what the end result would be. At this point, you're not feeding the C compiler code, you're feeding it a specificiation for what a program should do given these inputs and outputs.
Once compilers are capable of doing that, you won't need to write C code to begin with. You'll be able to simply tell the compiler what you want and let it do all the coding. But until this becomes the way compilers work, it will not be possible for a compiler to generate code as small and as fast as an experienced assembly language programmer.
--
"Convictions are more dangerous enemies of truth than lies."
Is it just me, or is there a lot of hype over an OS that doesn't seem to be much more then a real time executive? It seems to get its speed more from not having any protection, or abstraction layer then being in asm. Having worked with stripped down OS's/Execs for years, I'll tell you its better to just add more machine. They have their place on smaller micros like the motorola 68xx and intel 8051 families, but not the IA-32 series.
Merry Christmas, and in defense of this operating system, I would like to say that we are creating a developers environment..... We are not looking towards creating the most portable or even something for regular users... The V2 Labs guys (who created this in the first place) created this with a goal of maximizing multimedia. This operating system boots in about 1 second. So you can eventually have this sucker being your mp3 player in your car, or anything else and guess what... It will boot in 1 second!
Why would anyone want to work with this?
I work with it because there is a lot needed to make this a fully functional operating system. I don't know about most of you, but I wasn't able to help contribute to the base of any other operating system, and the experience for me is a good one. It may not turn out to be everything we want, but I am learning a lot about shells and operating systems.
Speaking of shells, if you want to get a shell for V2 OS, go to v2dash.hypermart.net It is up to version 0.007a (codename Golden Eye). It is open source, so if you want to help in the coding of a shell (unix style), now is a great opertunity..... Last of all Merry Christmas, Happy Chanukkah, and have a good day if you don't observe either of these holidays!
For one thing, it's been out less than a month. I've never seen development pick up so quickly on anything. Linux 0.01 was released in 1991, that was eight years ago. And there are people trying to compare.
Contrary to what most Linux advocates would seem to tell you, different OS's are good for different things.
V2 is not designed to be desperately stable, and certainly not portable. 100% assembler = 100% CPU power. This is a demo coder's OS, and damn cool it's going to be too. A lot of the old demoscene is waking up to this, and I've no doubt some very good stuff is going to show up soon.
But let's not take it for what it isn't. Yes, maybe this is a toy OS. Don't you guys have a sense of fun? :)
Martin J. Ling
ASM != arcane and difficult.
Well, ASM in general isn't (IA-32... well, Intel screwed up. Learn something easier, say MIPS or 68K or HC11 or PPC or StrongARM).
Also, C compiler optimization is a limit of knowledge of the optimization programmers (i.e., how well do they know the architecture, and what language construct modifications can reduce the architecture instructions [taking advantage of instructions that do more than one thing at the same time {integer division often returns both the quotient and the remainder - save several hundred cycles by storing the remainder if its used later}]). While *in general* a C compiler can probably generate pretty good assembly, nothing does beat handcrafted ASM (with proper comments), rather than looking at the compiler output before assembly.
Likewise, from the Art of Assembly (book available online, don't have URL) by Randall Hyde, it's possible to create lousy assembly that runs slower than its C counterpart, but it's also possible to make asm much faster than a C compiler can ever generate. Plus, if you know the processor well, you can take advantage of architectural efficiencies (like helping branch prediction) by reordering asm code without having to look too convoluted. Additionally, you get some raw power that is difficult to do with C (bit twiddling is much easier with asm than C, plus, it's easy to initialize a large data memory allocation in asm to some specific value (initialize pointer. Write value using largest processor can do, using a post-increment addressing mode. Is value of pointer > end of data block [which can be of various types]? If so, end, else repeat). Of course, this has serious alignment issues.