Tenacious C: Cool C IDE
tenaciousc.com
tenaciousc.com
'I like C, but I have to admit that, sometimes, “The Old Man of Programming” can be a bit of a killjoy. This is one of the most exciting eras in computer history, but lately, C’s acting like he doesn’t even want to have a good time. While the cool kids like Ruby and Haskell are living it up, C’s over in the corner obsessing over bits and bytes and memory alignment and pointers and the stack and machine architecture and unreachable allocations and multiple indirections…and it’s…kind of a buzzkill. You want to tell him, “Dude! Lighten up! This is supposed to be fun!”
But of course C can’t relax. He’s holding the entire computing universe on his shoulders, after all. It’s not turtles all the way down — it’s turtles all the way down, __then C__. Not a lot of room for fun underneath that, is there?
Is there?
Well. Here’s the secret: C does let loose sometimes. And after being bottled up for so long, when the release finally does come, it’s pretty much an F5 of crazy.'
http://www.lysator.liu.se/c/duffs-device.html
I've programmed in C a fair amount, but I am incapable of understanding the construct contained therein. Specifically, the interaction of the switch and the loop and all those fall-through cases. I would absolutely love it if some C-guru hn-er could describe it in layman's terms?
So, the idea behind Duff's Device is just to unroll a loop, dealing in an elegant (some would say abhorrent - they're wrong) way with the "leftover" portion.
So, the canonical Duff's is copying shorts, with the copy loop unrolled to eight copy statements inside the loop. If you want to copy, say 47 shorts, the loop would need to iterate five times, and there would be seven shorts left to copy.
Duff's uses the switch to jump into the middle of the loop just far enough to copy those seven leftover shorts (47 % 8 = 7). The do-while then proceeds to run through the five full iterations.
Modern compilers will do that for you now, though there are still applications for similar code.
Hope that helps.
* At the static level, what does it mean to start the loop at `case 0` then fall through to the termination of the loop? Part of me is surpisued that it even compiles (again, sorry); it's like the mechancis of the loop itself become dependent on the runtime input, at which point my brain begins to frazzle gently.
* Why is the `to` pointer never incremented? Is that some super-clever thing that I'm not seeing or is it just left out of the algorithm for clarity?
(EDIT: Formatting)
- the to pointer is not incremented because it corresponds to a single memory mapped output register (http://en.wikipedia.org/wiki/Duff%27s_device#Original_versio...). It does not have anything to do with the use if Duff's device.
hth
The basic idea is that the switch jumps into the body of the loop somewhere, after that it can do blocks of the same function over and over without having to do the conditional check to exit the loop as often.
For example, if you're copying memory, and you want to copy say, 9 bytes then you'd jump into the loop, copy 1 byte, run the conditional check, realize that you're not done, and then copy 8 more bytes, run the conditional check, realize you're done and exit the loop. For the 8*n times you run through the "unrolled" loop after that first pass through, there are a lot less conditional branches, so many processors can execute those instructions faster. That's the idea, anyway.
Duff's device just gets the (remainder of N/8) steps out of the way the first time through, then drops down to looping eight at a time. If it seems more complicated than that, you're probably overthinking it. It's "just" a creative abuse of C syntax, a bunch of offsets and gotos.
Sometimes low-level optimization like this makes a huge difference, but make sure it's a hotspot first, and that the compiler isn't already doing those things for you. Measurements will keep you objective.
Also, if you're doing a lot with C, check out Lua!
Lua replaced Python for me - it's a great language on its own. TCO and pattern matching (http://github.com/silentbicycle/tamale) go a long way.
A wise friend of mine once said it's much easier to optimize a correct program than debugging a heavily optimized one.
(After looking it up, I discovered it was from the same site.)
;)
...why would you want to do that for a C debugger?
By web-based I didn't mean it to be on the Internet.
My reasons: collaborative coding + debugging, and IDEs without needing an environment aside from your browser (coding + compiling + debugging code on the device it's made for).
What's left of it today: http://www.gravytea.com/labs/metacoding/
If you're a programmer, should know how your computer works; if pointers are too "hard" for you, you're in the wrong business. You're settling for mediocrity and belittling your own intelligence by assuming you're not capable of tackling this stuff the same way everyone else has.
Teachers are more valuable than belittlers. "This isn't hard" is not a lesson plan or a path to enlightenment.
Now if you don't like the features of this IDE, that's fair. You're free to stick to whatever you're currently using. Given that Tenacious C will be a paid app when it is done, I doubt I'll really be interested, given what I can use for free that gets the job done more than adequately.
I realise I'm being tangential now, but thought I'd mention it anyway.
If you can't understand that, I don't see how you are going to write a computer program. The deeper issues are things like object lifetimes, call-by-value versus call-by-reference semantics, and so on.