Re: For beginners. Why is C# better than Python for audio game development
Oh! Wow! Here we go again!
I won't even bother wasting my time debunking your claims in post 1 because I already have. As for your claim on how IO is slow... you say "IO". While I would normally stop and say that I know your talking about networking, let's go a bit more general here. First, do you know what this bit of assembly does?
mov eax, FFh
mov ebx, 60h
outb ebx, eaxYou probably don't, so I'll tell you. Hell, I don't think anyone does in this topic. But 'll tell you:
The first instruction moves 0xFF (255) into the EAX register. The second moves 0x60 into the EBX register. The third one is where the input/output comes in: we use the "outb" CPU instruction to write a byte (0xFF) to the keyboard (port 0x60). We don't read its response, but that wouldn't be overly difficult to do.
Do you know how long this takes? If your keyboard is embedded into the computer and directly attached, and the RTC is configured at its fastest tick speed without roling over (122 Us), anywhere between 1 tick (122 Us) to 5-6 ticks (610-732 Us). That's assuming that we're timing this with the real time clock though, which is usually (but not always) the case. And that's in microseconds. That's a millionth of a second. Talk about fast IO!
Of course, the CPU will be faster (the move instructions probably take about 0.0000001 Us), but my point is to demonstrate the "output" in IO. The reason I know how long this takes (in QEMU at least) is because I'm building an OS kernel that has a fully functioning asynchronous keyboard driver (bar a few synchronous spots, which need to be synchronous to work properly). The keyboard driver relies fully on interrupts for communication, and uses the programmable interrupt controller (PIC) timer to send data to the keyboard. When the keyboard replies, a hardware interrupt is fired, which is a way of saying "Hey, something's happened, go check!" I won't go into depth -- but I am working on preparing the code for posting on github.
Network IO is obviously going to take much, much longer than a few hundred Us. So is disk IO. But my overall point was that IO comes in many different forms, many of which are far faster than you think.
When I post it, I'll probably announce it on here if people who know Rust would like to help (as its written in Rust). If you know so much knowledge, why not put you to the ultimate test -- help me write my ATA/SATA driver -- which will be haaaaaaaaaaaaaaaaaaaaaard. I think. Or, even better, you can help me get plug-n-play support in! Now that'll be a challenge for ya!
I won't even bother to address your other points as others have already done so. Please, stop posting, go learn how to f**king code, then come back and start discussing things like this. If you actually knew how to code you'd know better than to ask or discuss topics like this -- its just as bad as asking "What's better, tabs or spaces?"
Edit: for those who are curious, I don't know how far I'll take the kernel. I certainly won't leave it where its at right now though -- but it can already do some things, and its only a week old! I might get into userland and stop there. I dunno though, but either way my curiosity about this shit is peeked and ready to learn all it can! OS development is fun!
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
