OSDev.org

REMEMBER: You must first remember what program you wanted to do originally. Write it down in your notes, and also here.

What program do you want to do? Based on that, is the right way to learn the different functions, googling each function you need to use as you need to know how to use them.

It's like studying a career for a field. You will not achieve much more than general knowledge if you study sequentially. You will achieve lots of stuff and goals if you treat your own ideas and programming goals, projects and actual applications you want to create, as the most important.

Just like when you choose a career. Here you need to choose a program or several ones you want to do, and then let all the available resources and information help you, but let your program dictate what you want to learn. After several programs or even after several pieces of your program, you'll find you'll become an expert all the same, but in a more useful way, writing the programs you wanted to create when you decided to learn how to program.

Mark12 wrote:Hey, I'm midway to learning C anyway. I don't think I should give up now.

I cannot agree with the suggestion to learn Java first. Please keep up with the C.

If anything, learning C helps you to understand how the actual machine works.

Go spend $50 on a single board computer like a raspberry pi or such and learn C on it.

Why?

Because you can fiddle with memory. You can fiddle with output ports. Watch lights flash on and off in a while() loop. Read the state of a button (1) and put a dot on the screen.

It is a visceral wonderful experience. Probably 99% of the people on this forum do what they do cause they love it. Just look at the thread about WOW Moments with your OS!

Java will never give you that.

The world needs more C programmers... Join Us.

This is the attitude I was talking about. Stay well away from it.

Love4Boobies wrote: .....People tend to get attached to things and form cults around them....

This is the attitude I was talking about. Stay well away from it.

Not quite clear how I was expressing an attitude other than perhaps cheering the C language camp at the end.

The meat of my post was to expound on the use of a raspberry pi as a means of learning the hardware through learning about C. I believe the term "visceral" sums it up.

Staying well away from it? Exactly how did anyone ever become a programmer without becoming enamored of it? without becoming obsessive about it? Geez this is osdev.org where people can tell you the Nth bit to set PE...

dchapiesky wrote:

Mark12 wrote:Hey, I'm midway to learning C anyway. I don't think I should give up now.

I cannot agree with the suggestion to learn Java first. Please keep up with the C.

If anything, learning C helps you to understand how the actual machine works.

Go spend $50 on a single board computer like a raspberry pi or such and learn C on it.

Why?

Because you can fiddle with memory. You can fiddle with output ports. Watch lights flash on and off in a while() loop. Read the state of a button (1) and put a dot on the screen.

It is a visceral wonderful experience. Probably 99% of the people on this forum do what they do cause they love it. Just look at the thread about WOW Moments with your OS!

Java will never give you that.

The world needs more C programmers... Join Us.

I think that a microcontroller like an ATMega (and a tool to write your program to it) would be a better investment.
They're usually cheaper and a lot more fun to play with, and you can learn a bit about electronics too.

I just meant that I think the healthy attitude to have is to work on the problems that are interesting to you instead of declaring your allegiance to a tool or to a camp. If you do the latter, you are likely to come up with inappropriate solutions or no solutions at all.

Regarding the C and the RPi, I also have to disagree. What's so different between pressing a key on your keyboard and having a pixel light up on the screen and having a button and an LED connected to a couple of GPIO pins and doing what is essentially the same thing? If he just wants to learn C, he probably shouldn't get distracted by what are esentially toys. And, as I've explained, conflating C with hardware programming is the wrong way to think about C.

If he really wants to learn about hardware, then he should pick up a book on computer architecture, assembly, and/or electronics. That's its own separate subject and there's no need to artificially fuse them together even if they may have some overlap as far as practical applications are concerned.

If your argument was that hardware programming can help him understand how to write better C or better code in general, then I also have to disagree. The real challenge in programming is designing good abstractions and having good theoretical grounding (algebra, trig, calculus, how to design and analyze an algorithm, etc.). Seeing your loop in action by playing around with blinky lights, buzzers, and spinning things will only take him so far. Most children no older than 5 can write that sort of code with a little exposure but they certainly can't write any code that's worth anything.

So where is this thread going?

Despite the title, the thread was always about C and learning C. I don't think we've moved away from that.

It's alright for people to disagree. Perhaps you can still get something useful to you out of all these replies.

When I got started in osdev, I avoided assembly like the plague. But I eventually learned it through osmosis, because half of the code examples that you find are written in assembler.

And, assembler is as close to the language that the CPU understands that you can get, short of using a hex editor.

C, on the other hand, will generate several CPU instructions per line of code. To me, the 1 to 1 nature of assembly lines to CPU instructions makes it much easier to understand when you are just getting started.

I would start with assembly, then move to C, then C++, then C#. But that's just my opinion. If someone had told me to learn things in that order 7 years ago, I would have just ignored them. So, whatever...

Why is it relevant to know precisely what instructions a CPU is executing when running a program compiled from C, as long as it adheres to the program's semantics? And how do you translate that knowledge across compilers or architectures?

(I'm not counting the incredibly rare case where a super tight loop needs to be micro-optimized as hell because slightly more powerful hardware is unavailable since that does sound like a valid use for assembly, unlike simply wanting to have a single instruction generated per line of code, which to me sounds like an arbitrary desire.)

Happy New Year!

I read my post again after a while... I see how you read it now. No disagreements just the warm glow of my old 20" CRTs cooking my brains.

Someone mentioned osmosis - it's true... OSDev best place for it.

May your OS not SEGV

dchapiesky wrote:May your OS not SEGV

That's unlikely to happen, unless you run your OS inside of another OS.

Happy New Year!

Happy new years to all of you too.

Love4Boobies wrote:Why is it relevant to know precisely what instructions a CPU is executing when running a program compiled from C, as long as it adheres to the program's semantics? And how do you translate that knowledge across compilers or architectures?

Because, as an os developer, you are going to be responsible for implementing a lot of platform specific code, like interrupt handlers, before you can do things like open files or create threads.

And, as I said, a lot of examples on this site are written in assembly only. So you're probably going to need to learn it anyway.

In OS development, there are a few things that you just can't do in C, so if you had to pick just one language...

But I was just trying to point out that IF you wanted to understand how your machine really worked, I would recommend starting with assembler, so that you could see every stage of the process, rather than just typing one line of code that invisibly does 100 things, depending on which compiler you used.

But, either way works. In the end, you'll end up at the same place.

Well, the question was about which order things should be learned in. I'm not advocating that assembly not be used when writing a kernel. Obviously, C is designed to be portable so it's more of a common denominator of typical machines so you can't really write a full OS in standard C. But the OP expressed his interest in learning C, not learning how the hardware works. (And I don't think assembly alone teaches that very well anyway because it misses out on all the architectural details.) However, "higher-level" languages do make it possible to write most of an OS portably (you can even abstract interrupts using mechanisms such as signals---in the case of C, that is their original rationale), with very few exceptions (like context switching and other platform-specific things, such as switching CPU modes in the case of x86).