How many lines of code in your kernel?
- einsteinjunior
- Member
- Posts: 90
- Joined: Tue Sep 11, 2007 6:42 am
How many lines of code in your kernel?
Some software designers say designs with a lot of source code is nice,that is to say big is beautiful ,some say the opposite.
So what do you say and whats the size of your operating system kernel.
So what do you say and whats the size of your operating system kernel.
Lines of code (LOC), to me, is a completely useless statistic that is only useful when you're a code monkey working for one of the companies that gets regularly featured on the front page of The Daily WTF.
Much more important is good commenting, good documentation, and clear algorithms. I guess to summarise: readability. If other programmers can pick up any part of the code and understand it, then understand where it fits into the whole project, without too much difficulty, then the programmer has done well.
Aside from which, 1000 lines of assembly code could be represented in 100 lines of C source (or something like that... an actual ratio isn't what I'm trying to illustrate here). One coder might put in 50 lines of comments to every 200 lines of code, another might do 50:50.
Much more important is good commenting, good documentation, and clear algorithms. I guess to summarise: readability. If other programmers can pick up any part of the code and understand it, then understand where it fits into the whole project, without too much difficulty, then the programmer has done well.
Aside from which, 1000 lines of assembly code could be represented in 100 lines of C source (or something like that... an actual ratio isn't what I'm trying to illustrate here). One coder might put in 50 lines of comments to every 200 lines of code, another might do 50:50.
Code: Select all
[10:38:30] aubergine: ~/pedigree/src/system
$ find ./ -name *.h -or -name *.cc | grep -v autogen.h | xargs cat | wc -l
34591
We comment heavily, by the way.
Removing comments and blank lines we get:
Code: Select all
[10:57:04] aubergine: ~/pedigree/src/system
$ find ./ -name *.cc -or -name *.h | grep -v autogen.h | xargs cat | grep -v '\(^ *\*\)\|\(^ */\*\)\|\(^ *//\)\|\(^ *$\)' | wc -l
20209
Last edited by JamesM on Wed May 07, 2008 4:03 am, edited 1 time in total.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
woohoo, beat you
That's what you get for using assembly
Code: Select all
/cygdrive/D/programmeren/asm/mos>find ./ -name *.c -or -name *.h -or -name *.bas -or -name *.bi
-or -name *.asm -or -name *.S -or -name *.inc | xargs cat | wc -l
84867
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
I haven't had time to work on my tiny, fledgling kernel for over 2 years now, so counting its lines would be a bit pointless...
However, LOC has enormous value as a tool for software estimation. It is much easier to estimate a large project by LOC and convert it to effort/schedule using a software estimation tool than it is to estimate task efforts/durations directly and add them all up. The results tend to be much more accurate too. Read this if you're interested.
If you're using LOC to decide which code base is somehow "better" than the other, or if you're using it to judge the individual productivity or capabilities of developers, then yes, it's a terrible metric.Yayyak wrote:Lines of code (LOC), to me, is a completely useless statistic that is only useful when you're a code monkey working for one of the companies that gets regularly featured on the front page of The Daily WTF.
However, LOC has enormous value as a tool for software estimation. It is much easier to estimate a large project by LOC and convert it to effort/schedule using a software estimation tool than it is to estimate task efforts/durations directly and add them all up. The results tend to be much more accurate too. Read this if you're interested.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Citadel - ~9k lines of C, mixed with Assembly.
Zenobit 1dc0.1 - 13140 lines of C, Assembly.
Zenobit 1dc0.2 - 16180 lines of C, Assembly.
And so begun the project of making _good_ code,
concise, minimal code ...
Zenobit 2dc0.0 - ~6k lines of C, Assembly.
Zenobit 3dc0.0 - ~4k lines of C, Assembly.
Amethyst 1dcA - ~2k lines of C, Assembly.
~Z
Zenobit 1dc0.1 - 13140 lines of C, Assembly.
Zenobit 1dc0.2 - 16180 lines of C, Assembly.
And so begun the project of making _good_ code,
concise, minimal code ...
Zenobit 2dc0.0 - ~6k lines of C, Assembly.
Zenobit 3dc0.0 - ~4k lines of C, Assembly.
Amethyst 1dcA - ~2k lines of C, Assembly.
~Z
Using Sloccount to count:
Code: Select all
SLOC Directory SLOC-by-Language (Sorted)
18055 kernel cpp=16807,asm=1248
8366 libraries ansic=8007,asm=359
4259 drivers cpp=4259
1975 applications ansic=1940,asm=35
933 tools ansic=516,sh=143,yacc=93,asm=85,lex=67,ruby=29
Totals grouped by language (dominant language first):
cpp: 21066 (62.72%)
ansic: 10463 (31.15%)
asm: 1727 (5.14%)
sh: 143 (0.43%)
yacc: 93 (0.28%)
lex: 67 (0.20%)
ruby: 29 (0.09%)
Total Physical Source Lines of Code (SLOC) = 33,588
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Here are my stats: (including comments)
Kernel: 4k lines
Drivers: 2k lines
Toolchain (Assembler, Linker, Interpreter, Compiler, Jit-Compiler): ~34k (Self written as my os is written in a safe/bytecode language and uses a jit compiler to run applications; it had to be self written because my os won't support native applications (at least this is a very low priority task) and I want to be able to run the entire toolchain inside my os)
Most of the code is written in my own programming language (including the kernel and the virtual machine / jit compiler). Some code is java (an interpreter for my language and the source code -> bytecode compiler so that I can run the bytecode -> native compiler on a host operating system that supports java; java will be easy to support in my os as it is a bytecode language, too). Some hal functions are written in assembly.
Kernel: 4k lines
Drivers: 2k lines
Toolchain (Assembler, Linker, Interpreter, Compiler, Jit-Compiler): ~34k (Self written as my os is written in a safe/bytecode language and uses a jit compiler to run applications; it had to be self written because my os won't support native applications (at least this is a very low priority task) and I want to be able to run the entire toolchain inside my os)
Most of the code is written in my own programming language (including the kernel and the virtual machine / jit compiler). Some code is java (an interpreter for my language and the source code -> bytecode compiler so that I can run the bytecode -> native compiler on a host operating system that supports java; java will be easy to support in my os as it is a bytecode language, too). Some hal functions are written in assembly.
- fingerprint211b
- Posts: 13
- Joined: Thu May 29, 2008 2:34 pm
Ok, I'm officially amazed ...Korona wrote:Here are my stats: (including comments)
Kernel: 4k lines
Drivers: 2k lines
Toolchain (Assembler, Linker, Interpreter, Compiler, Jit-Compiler): ~34k (Self written as my os is written in a safe/bytecode language and uses a jit compiler to run applications; it had to be self written because my os won't support native applications (at least this is a very low priority task) and I want to be able to run the entire toolchain inside my os)
Most of the code is written in my own programming language (including the kernel and the virtual machine / jit compiler). Some code is java (an interpreter for my language and the source code -> bytecode compiler so that I can run the bytecode -> native compiler on a host operating system that supports java; java will be easy to support in my os as it is a bytecode language, too). Some hal functions are written in assembly.
Here are my statistics :
ansic: 323 (89.97%)
asm: 29 (8.08%)
sh: 7 (1.95%)
It's a small kernel (if I dare call it that) I'm working on for the purpose of learning assembly and improving my C. It's currently able to use VGA in 25x80 text mode (via accessing 0xb8000), and I'm trying to create multiple virtual terminals. But it can't get any input yet (I'll get on that a bit later)
It's not really going to be a real OS, I'm trying to make a bootable miniOS that will check hardware (eg. check if memory is working properly), since I'm a beginner. It will consist of nothing but the kernel, with built in functions for checking hardware, it won't have, or be able to call any external programs...
That part written in bash is a script that automates compiling, linking and then puts the binary (along with grub) on a floppy image, like the Bare Bones tutorial.