OSDev.org

Hi,

Rusky wrote:

Casm wrote:

Love4Boobies wrote: Nah, even today. We just tell people they're good at it to trick them into avoiding a premature optimization. For the moment, they're very far from beating an experienced assembly programmer.

I would second that; especially if there is a loop with a large number of iterations involved. In assembly language there can be a noticable blip whilst the loop is executing, but the same thing coded in C can leave you thinking that the computer has hung.

Got any evidence of that? No? Didn't think so.

Got any evidence of the opposite? No? Didn't think so.

If you're writing a large application, the normal "rule of thumb" is that 90% of CPU time will be spent in 10% of the code. For the other 90% of the code a good/experienced programming will care more about code maintenance than optimising, but a compiler won't care and will optimise it anyway; and as a result for about 90% of the code the compiler will beat a good/experienced assembly programmer.

For the remaining 10% of the code (where the CPU spends about 90% of the time); most people would start by disassembling the compiler's output and then tweaking it. Done like this, for parts that are worth optimising, assembly should never be worse than C. It's also not too hard for a good/experienced assembly programmer to get (sometimes significant) performance improvements.

Now, for an entire OS written in assembly, the same thing applies - you can expect about 90% of the code to be worse than compiler generated code and 10% to be the same or better; and you can expect the CPU to spend about 90% of it's time in better assembly code and 10% of it's time in worse assembly code.

This "90% and 10%" thing doesn't apply for some parts though. For something like a micro-kernel it's a lot closer to "50% and 50%"; and for some things (e.g. "PC BIOS" boot code) you're mostly screwed if you try to use a compiler.

None of the above mentions the effect on development time either. As a rough estimate, it will take about twice as long to do anything in assembly, regardless of what it is.

If you weigh up the advantages (faster were it matters) and disadvantages (slower were it doesn't matter, longer development time, no portability); the most obvious choice is to do everything you can in something like C and then worry about optimising small parts in assembly later (after you've done profiling, etc).

Of course in some cases there may be other reasons to use assembly beyond performance alone (for example, maybe you just like assembly more).


Cheers,

Brendan

Brendan wrote:[...stuff about ASM coders being able to beat the compiler deleted, which I don't want to go into discussing here, followed up by (emphasis mine)...]

If you weigh up the advantages (faster were it matters) and disadvantages (slower were it doesn't matter, longer development time, no portability); the most obvious choice is to do everything you can in something like C and then worry about optimising small parts in assembly later (after you've done profiling, etc).

Thank you.

For portability reasons, I write all the portable code in C/C++ but, for the 10/50% that Brendan mentions, I provide optimized assembly routines which the build system will use instead, provided they are present for that particular architecture (although for now I only have working builds for x86 and x86-64). Everything is done automatically so I don't need to maintain the makefiles for this purpose. The obvious downside is that I have to keep the HLL and assembly code in sync.

Solar wrote:

Brendan wrote:[...stuff about ASM coders being able to beat the compiler deleted, which I don't want to go into discussing here, followed up by (emphasis mine)...]

If you weigh up the advantages (faster were it matters) and disadvantages (slower were it doesn't matter, longer development time, no portability); the most obvious choice is to do everything you can in something like C and then worry about optimising small parts in assembly later (after you've done profiling, etc).

Thank you.

Maybe you forgot a few things?

1. It is more fun to write in assembly than in C

2. It is more of a challenge to use assembler than C

3. If you do the whole project in asembler, rather than parts in C, you can use whatever memory model and interface specification you want without being locked-up to what C uses. For this reason, comparisions between whole assembly design and mixed designs might not be valid. IOW, if your C compiler dictates that you must pass parameters on the stack, and use ebp to reference them, there is not much of optimization to do. One of the problems with C and HLLs in general, is that only one parameter can be passed as a result. The rest needs to be passed by reference/pointers. In an assembly only design, any number of registers can be input / output.

rdos wrote:Maybe you forgot a few things?

Maybe you forgot to not get on everyone's nerves.

rdos wrote:1. It is more fun to write in assembly than in C

That's in the eye of the beholder. I disagree with you on that point, because...

rdos wrote:2. It is more of a challenge to use assembler than C

...when programming, I am not looking for a challenge, but for results. Virtually all of the time, I get better results in shorter time when not opting for ASM.

rdos wrote:3. If you do the whole project in asembler, rather than parts in C, you can use whatever memory model and interface specification you want without being locked-up to what C uses.

I couldn't care less. I prefer being able to interface with a multitude of other languages and toolchains by sticking to established models and interfaces.

Regarding point 3, the opposite is actually true. The assembly code will be tied to a particular memory model while for most of the C code, it will depend on the compiler and how it is configured.

Brendan wrote:It's also not too hard for a good/experienced assembly programmer to get (sometimes significant) performance improvements.

Looks like we agree. I was asking for evidence that "C compilers usually generate lousy assembler code." Everything on that page is for a very specific situation. Using assembly to help your compiler's optimizer with what it doesn't know is a far cry from writing everything in assembly, and will probably provide much more noticeable benefit for much less time.

Compilers usually do generate lousy assembly code, our point is just that it usually doesn't matter not that it's not true. If you want proof, look at your compiler's assembly output. I don't think I have never seen an output which I couldn't have optimized heavily---apart from very simple snippets of HLL code, perhaps.

Love4Boobies wrote:Regarding point 3, the opposite is actually true. The assembly code will be tied to a particular memory model while for most of the C code, it will depend on the compiler and how it is configured.

Not true. Most popular C compilers only support one memory model (flat). If you don't find the protection features of the flat memory model adequate, there is no other option.

And regaring assembly being tied to a particular memory model, that is simply not true. My kernel is using a mixed 16 and 32 bit memory model, and sometimes also flat addressing, something that no C compiler can do. Not even OpenWatcom supports mixing 16, 32 and flat addressing modes.

rdos wrote:And regaring assembly being tied to a particular memory model, that is simply not true. My kernel is using...

...a very leet combination of tricks and techniques, yes we heard.

And if you want to change that particular mix, the only option is to rewrite significant parts of the code. That is what was meant with ASM code being "tied to a particular model".

Can we finally put this latest round of "only ASM coders using segmented memory are really leet" to rest? It's been going on for weeks now, and I'm getting really tired of it.

Do use your ASM flavor of choice, but please don't flaunt it at every appropriate and many an inappropriate moment. That's just flamebaitin', that is.

Why not instead acknowledge the fact that it is the inabilities of C compilers that governs chip-design? Because this is what has happened on x86, and especially when designing x86-64. Some day this might change when the clock-frequencies cannot be increased, and multicore will not solve the problems, although I see no signs of it at the moment. What is happening instead is that more and more tasks are "out-sourced" to additional processors that doesn't have to comply with bloated OS designs like Windows or Linux.

Some examples:
1. Network cards use memory buffers and bus-mastering in order to offload network traffic. We also see checksum calculation offloading. Realistically, checksums should not be faster in a network chip than in a x86 processor.

2. AHCI offload SATA communication to hardware by use of memory buffers and bus-mastering. Originally, PIO-mode was used with IDE, and then we had DMA.

3. USB also use elaborate memory buffers and bus-mastering.

4. More and more of graphics is moved to GPUs.

Hi,

As is often the case with [x] vs. [y] questions, I think the OP has been scared off by the strong polarisation of views.

@op: As stated in the first couple of posts, if you are proficient in C but not in assembly, you really need to do some applications programming in assembly before starting on an OS. Then, you will get to see the pitfalls and benefits of both languages first-hand.

Solar wrote:Can we finally put this latest round of "only ASM coders using segmented memory are really leet" to rest?

I think you'll find it's 1337

Locked.