Many hacks, on their face, are pointless indulgences. However, that's true only on their face. After all, Linux was a pointless indulgence at one time.
My personal hobbies, such as twiddling with 80s video game equipment, are equally indulgent. They also, however, fill a creative need, and they hone my skills.
For instance, I wrote a super fast square root routine for the Intellivision. It's about 7x to 15x as fast as the built in routine, and it even does fixed-point square roots. Its run-time is very predictable and it handles the full range of unsigned 16-bit numbers--neither of which describe the built in code. I had no idea how to compute a square root before I wrote this routine, but I needed it for one of my (also unimportant) projects.
Is it really useful? Not directly, except to the handful of people that enjoy twiddling with Intellivision source code. (I'd guess that's no more than a dozen of us, and only maybe 2 or 3 people in that group might actually use this code.) But, I learned lots of neat tricks as I optimized the algorithm and wrote the assembly. Not only did I learn how to compute a square root, but also I learned how to optimize that implementation multiple ways. I even came up with some optimizations that went beyond the C code I found online. All this makes me a better programmer.
So is this a pointless indulgence? If you didn't enjoy yourself while you did it; if you didn't grow somehow as a person or as a hacker as you did it; if you didn't somehow benefit yourself, then yes. Otherwise, it was FAR from pointless.
File a bug report with the vendor of the compiler?
Examine the assembly output of the compiler and verify that the compiler output bogus code?
I find that the believability of compiler bug reports goes way up if you actually look at the compiler's output and can say "See! There it is! It's wrong!" And once you do that, you should point it out to the vendor so they fix it. (I say all this as someone who actually has spent signficant time filing compiler bug reports of my own.)
Finding a bug and just kluging around it might be a nice short term expedient, but it doesn't increase the long-term quality of the tools.
I'm someone who deals with optimized code all the time, and for good reason. When you're programming an embedded system and you're trying to tweak every last penny out of it, you're in a different world than the "throw a faster Pentium at it" crowd.
Personally, I prefer mnemonic variable names that aren't terribly long, and fairly uniform in length. I find that the physical layout of the code communicates as much or to me than verbose variable names.
It's much easier to look for i, j and k as loop iterators too, than "arrayIndex." It lets me skip the carrier and get to the signal. IDIOMS ARE YOUR FRIENDS!
Anyone else find it ironic that mathmeticians make their language as terse as possible, whereas computer science (which is really applied discrete math in most cases) wants us to be as verbose as possible. Maybe more people would find math more approachable if it were a little more verbose.
There are precisely two places I'll comment every line, and it's for the same reason: Assembly code, and tricky high-level language code. Otherwise, I stick to the occasional one-liner if something's non-obvious, or blocks of "big picture" / "middle picture" comments.
Here's an example of how I code. It's not the most refined example, but it illustrates a range of tricky and non-tricky code. (This file actually could use some more per-line comments in the blitter.)
Here's an example of how I assembly code. I use a combination of block comments to say what the next block does, and line-by-line comments to give the blow-by-blow.
Heh... I was a BSEE. I can proudly state that I made out with the entire female component of MSEE Class of 96 and BSEE Class of 97 at my school. All three of them, total.;-)
I think the goal is to have edges on as many pixel boundaries as possible, with as great a contrast as possible. That way, the monitor can align the video card's notion of a pixel with its own.
The grey checks in the empty image are probably too large and too low contrast to be completely effective, although I imagine they might help a little.
The "printf without prototype" won't work with the TI DSP compiler for the C6000 DSP. I know this from experience. (Many years of experience.)
Most CPUs have an ABI that allow variadic functions to automagically work, even if there's no prototype in scope. In the Bad Old Days, when arguments were always passed on the stack, this happened with no additional work. In fact, I think that's how variadics were born--someone figured out that if they had a pointer to the first argument to a function, all the others were on the stack next to it. All function calls (variadic or not) sucked though, performance wise, due to heavy stack traffic.
Later, when compilers started passing args in registers, it started to get weird for variadic functions. If the arguments are in registers, you can't take the address of them. All the va_start and friends won't Do The Right Thing anymore.
So, what it appears many architectures do, is that they pass at least some arguments in registers anyway. If a called function is a variadic function, the called function writes the register arguments to the stack. (Alternately, the caller might do this in addition to passing the args in registers.)
Since it's usually impossible to pass ALL arguments in registers, some will be passed on the stack anyway if the function has many arguments. If the callee's responsible for putting register arguments on the stack, the first "pushed" operand will be pushed by the caller with a gap on the stack to make room for the other register arguments, in case the called function is variadic.
ANSI doesn't require all this. So, not all compilers go to these lengths to make variadic functions work sans prototype. The TI C6x DSP compiler is such a compiler. It happily passes
the first ten arguments in the register file,
EXCEPT when it knows the called function is
variadic. So, bad things happen when you call
printf w/out a prototype.
The following sequence seems to do the trick w/ GIMP 1.2.x:
Create a new greyscale image that's the size of your screen
Go to "Filters->Render->Patterns->Checkerboard. " Pick a checkerboard size of 1.
That should get you a checkerboard pattern on a 1-pixel increment. I haven't seen what this does for an LCD monitor's ability to fine tune an analog signal (since I don't own such a display), but I think it's the pattern you're using. It's the same fill pattern the old monochrome Macs used for their desktops. LOTS of edges to sync on, on every line!:-)
Of course, on some level, it almost makes sense that if you're living here, you should have some say in how the country is run. Even if you're here "illegally." There should be some way within the system to change it, including by those disenfranchised by the system.
I know he's not. I was thrilled when I finally got my kernel compiles under two hours, by upgrading the CPU and RAM, and configuring out a bunch of stuff. (Went from 486DX33 w/ 4MB to 486DX2-66 with 8MB.) That was back in the 0.99.15 days. I seem to recall an hour-and-a-half was about right for a compile on my faster setup.
I once tried compiling a kernel on a 386sx16, but gave up on it. I found a 486 to do the compile on, since my roommate needed to use the 386, and we weren't technically supposed to be running Linux on the 386 anyway.
I see the same bug, and I seem to recall there was a reflow bug that was fixed in 1.8alpha that mostly fixes this. I'm not 100% sure though. I hit it all the time on my slower Mac before, and I think I've hit it once since upgrading to 1.8alpha.
The weirdest thing is if you switch tabs and come back (without refreshing), the page will fix.
Sometimes I get a weird layout problem where the center table (where all the articles are) overlaps the navbar at the left. Seems to happen on slower computers more. Could be a style sheet / reflow related thing.
It's not a memory leak unless you forget where your "arena" is. It's just a poor choice of allocation/deletion strategy for that app.
If you're truly running in steady state, then the traditional malloc/free (or new/delete) approach should work fine instead. Either that, or you shouldn't be allocating much any more.
If you do have discrete processing steps (e.g. sending off a bunch of queries, constructing a web page, whatever) that are largely self-contained, though, the arena strategy can work well. I do agree that it's best for batch-oriented tasks.
Slashdot Mirror
Go get an Intellivision and play 4-Tris. ;-)
--JoeMany hacks, on their face, are pointless indulgences. However, that's true only on their face. After all, Linux was a pointless indulgence at one time.
My personal hobbies, such as twiddling with 80s video game equipment, are equally indulgent. They also, however, fill a creative need, and they hone my skills.
For instance, I wrote a super fast square root routine for the Intellivision. It's about 7x to 15x as fast as the built in routine, and it even does fixed-point square roots. Its run-time is very predictable and it handles the full range of unsigned 16-bit numbers--neither of which describe the built in code. I had no idea how to compute a square root before I wrote this routine, but I needed it for one of my (also unimportant) projects.
Is it really useful? Not directly, except to the handful of people that enjoy twiddling with Intellivision source code. (I'd guess that's no more than a dozen of us, and only maybe 2 or 3 people in that group might actually use this code.) But, I learned lots of neat tricks as I optimized the algorithm and wrote the assembly. Not only did I learn how to compute a square root, but also I learned how to optimize that implementation multiple ways. I even came up with some optimizations that went beyond the C code I found online. All this makes me a better programmer.
So is this a pointless indulgence? If you didn't enjoy yourself while you did it; if you didn't grow somehow as a person or as a hacker as you did it; if you didn't somehow benefit yourself, then yes. Otherwise, it was FAR from pointless.
--JoeThe real bug, as best as I can see, would be compilers which print "no" but don't issue a warning about numeric overflow on the line "bar.c = black".
--JoeDid it ever occur to you, at this point, to:
I find that the believability of compiler bug reports goes way up if you actually look at the compiler's output and can say "See! There it is! It's wrong!" And once you do that, you should point it out to the vendor so they fix it. (I say all this as someone who actually has spent signficant time filing compiler bug reports of my own.)
Finding a bug and just kluging around it might be a nice short term expedient, but it doesn't increase the long-term quality of the tools.
--JoeHear, hear!
I'm someone who deals with optimized code all the time, and for good reason. When you're programming an embedded system and you're trying to tweak every last penny out of it, you're in a different world than the "throw a faster Pentium at it" crowd.
Personally, I prefer mnemonic variable names that aren't terribly long, and fairly uniform in length. I find that the physical layout of the code communicates as much or to me than verbose variable names.
It's much easier to look for i, j and k as loop iterators too, than "arrayIndex." It lets me skip the carrier and get to the signal. IDIOMS ARE YOUR FRIENDS!
Anyone else find it ironic that mathmeticians make their language as terse as possible, whereas computer science (which is really applied discrete math in most cases) wants us to be as verbose as possible. Maybe more people would find math more approachable if it were a little more verbose.
--JoeThere are precisely two places I'll comment every line, and it's for the same reason: Assembly code, and tricky high-level language code. Otherwise, I stick to the occasional one-liner if something's non-obvious, or blocks of "big picture" / "middle picture" comments.
Here's an example of how I code. It's not the most refined example, but it illustrates a range of tricky and non-tricky code. (This file actually could use some more per-line comments in the blitter.)
Here's an example of how I assembly code. I use a combination of block comments to say what the next block does, and line-by-line comments to give the blow-by-blow.
Actually, no. They were fairly conservative girls, quite unsurprisingly.
Oh, and our graduating classes weren't THAT big. On the order of 30-40.
Heh... I was a BSEE. I can proudly state that I made out with the entire female component of MSEE Class of 96 and BSEE Class of 97 at my school. All three of them, total. ;-)
And they weren't bad looking, either.
--JoeTrue enough. Point taken.
Hey, at least it raises the bar a little--you have to campaign the whole state. :-)
I think the goal is to have edges on as many pixel boundaries as possible, with as great a contrast as possible. That way, the monitor can align the video card's notion of a pixel with its own.
The grey checks in the empty image are probably too large and too low contrast to be completely effective, although I imagine they might help a little.
--JoeThe two are related though. If you replace the values in Pascal's triangle with their parity (odd/even), you get Sierpinski's triangle. (Try it!)
The "printf without prototype" won't work with the TI DSP compiler for the C6000 DSP. I know this from experience. (Many years of experience.)
Most CPUs have an ABI that allow variadic functions to automagically work, even if there's no prototype in scope. In the Bad Old Days, when arguments were always passed on the stack, this happened with no additional work. In fact, I think that's how variadics were born--someone figured out that if they had a pointer to the first argument to a function, all the others were on the stack next to it. All function calls (variadic or not) sucked though, performance wise, due to heavy stack traffic.
Later, when compilers started passing args in registers, it started to get weird for variadic functions. If the arguments are in registers, you can't take the address of them. All the va_start and friends won't Do The Right Thing anymore.
So, what it appears many architectures do, is that they pass at least some arguments in registers anyway. If a called function is a variadic function, the called function writes the register arguments to the stack. (Alternately, the caller might do this in addition to passing the args in registers.)
Since it's usually impossible to pass ALL arguments in registers, some will be passed on the stack anyway if the function has many arguments. If the callee's responsible for putting register arguments on the stack, the first "pushed" operand will be pushed by the caller with a gap on the stack to make room for the other register arguments, in case the called function is variadic.
ANSI doesn't require all this. So, not all compilers go to these lengths to make variadic functions work sans prototype. The TI C6x DSP compiler is such a compiler. It happily passes the first ten arguments in the register file, EXCEPT when it knows the called function is variadic. So, bad things happen when you call printf w/out a prototype.
--JoeFair enough, but the ? is the sequence point that matters in this particular discussion.
The following sequence seems to do the trick w/ GIMP 1.2.x:
That should get you a checkerboard pattern on a 1-pixel increment. I haven't seen what this does for an LCD monitor's ability to fine tune an analog signal (since I don't own such a display), but I think it's the pattern you're using. It's the same fill pattern the old monochrome Macs used for their desktops. LOTS of edges to sync on, on every line! :-)
--JoeYour teh funnay! ;-)
That is, unless Bill O'Reilly, Sean Hannity and Alan Colmes are there to play MST3K to it.
(Colmes being there for "balance." Harumpf.)
--JoeSenator Foghorn Leghorn, that's a good one!
Of course, on some level, it almost makes sense that if you're living here, you should have some say in how the country is run. Even if you're here "illegally." There should be some way within the system to change it, including by those disenfranchised by the system.
I know he's not. I was thrilled when I finally got my kernel compiles under two hours, by upgrading the CPU and RAM, and configuring out a bunch of stuff. (Went from 486DX33 w/ 4MB to 486DX2-66 with 8MB.) That was back in the 0.99.15 days. I seem to recall an hour-and-a-half was about right for a compile on my faster setup.
I once tried compiling a kernel on a 386sx16, but gave up on it. I found a 486 to do the compile on, since my roommate needed to use the 386, and we weren't technically supposed to be running Linux on the 386 anyway.
--JoeI see the same bug, and I seem to recall there was a reflow bug that was fixed in 1.8alpha that mostly fixes this. I'm not 100% sure though. I hit it all the time on my slower Mac before, and I think I've hit it once since upgrading to 1.8alpha.
The weirdest thing is if you switch tabs and come back (without refreshing), the page will fix.
--JoeWhere are they buried? I couldn't find them at all!
Sometimes I get a weird layout problem where the center table (where all the articles are) overlaps the navbar at the left. Seems to happen on slower computers more. Could be a style sheet / reflow related thing.
"(!tfel re'uoY) !thgir eht no sdneirf on tog t'nia uoY (!thgir er'uoY) !tfel eht no sdneirf on tog t'nia uoY"
It's ok. They're speaking Chinese.
It's not a memory leak unless you forget where your "arena" is. It's just a poor choice of allocation/deletion strategy for that app. If you're truly running in steady state, then the traditional malloc/free (or new/delete) approach should work fine instead. Either that, or you shouldn't be allocating much any more.
If you do have discrete processing steps (e.g. sending off a bunch of queries, constructing a web page, whatever) that are largely self-contained, though, the arena strategy can work well. I do agree that it's best for batch-oriented tasks.
--Joe