Personally, I don't think there should be any callee-save registers. Let the compiler's register allocator decide what registers need to be saved prior to a call, instead of having to save a swath of them because the caller might have wanted them saved.
It's not that simple, or everyone would be doing this. I could just as easily say this:
Personally, I don't think there should be any caller-save registers. Let the compiler's register allocator decide what registers need to be saved prior to a function body, instead of having to save a swath of them because the callee might clobber them.
I haven't given this a lot of thought myself, but it seems most platforms have come to the conclusion that a mix of caller- and callee-saved registers is best. (Except that oddball SPARC of course.)
Despite worm holes, warp drive, hyper drive, tachyon fields, and all the other SF solutions, nobody has ever come up with a mathematically viable solution to Einstein's limitation on travel speeds in the universe.
What I'm saying is that leaving things in memory, rather than pulling them into registers and potentially having to spill registers as a result, can often be more efficient.
Ok, then leave the values in memory. Extra regs don't prevent you from doing that.
It's been shown that passing parameters in registers can be a bad things sometimes, because you often immediately have to move those registers to non-transient registers, so there's no win.
Interesting. I had never heard that. But regardless, it's still the calling convention's fault, not the extra registers.
Have you ever looked at the function entry and exit for for processors like MIPS or PowerPC? There can easily be 20-40 instructions (at 4 bytes per instruction) to save and restore registers. Sometimes fewer registers is a win.
Ridiculous. You're saying that architectures with lots of regs are inferior because they make you save lots of registers at certain times, but reg-starved architectures make you save them all the time, all over the place, in any code that feels the slightest register pressure.
At best, the problem you describe indicates those architectures use too many callee-save registers in their calling conventions. Having more caller-save registers are a pure win from this perspective.
Sorry, this has nothing to do with the potato clock at all. The energy for a potato clock doesn't even come from the potatoes. It comes from the electrodes "dissolving" into the potatoes. The electrodes are consumed in the process.
The article describes a microbial fuel cell that is totally different.
Um, no. That's not how the slingshot effect works. It's not free energy generated by a planet's rotation.
I'm not expert, but I think the key to the slingshot effect is that you always receed from a planet's gravity well at the same speed as you approached, but nobody ever said it had to be the same direction. So, to put it simply, suppose a certain planet is travelling at 100m/s relative to the sun, and you are sneaking up behind it at 120m/s. Relative to the planet, you are approaching at 20m/s. After you pass it, you'll receed at the same speed, 20m/s. If you choose to receed from the planet in the direction it's revolving, then you'll leave at 140m/s relative to the sun, having acquired the additional 40m/s at the expense of the planet's kinetic energy.
Of course, this is a one-dimensional example of a three-dimensional phenomenon, but you get the idea.
Why do we listen to what Eugenia says all of a sudden? It seems Slashdot has one of her reviews every few days lately. This is not News For Nerds, is it?
I, for one, think you'd have to try pretty hard to find SuSE's installation difficult. She complains about the problems for newbies, but this is SuSE 8.1 Professional. Yes, it's for professionals.
Having said that, I think the installer is wonderful for newbies. I like the fact that you get a summary (which is like a web page, as Eugenia said), and you can drill down as deep as you want to customize it. If you like the defaults that the installer has chosen, you can click OK and go right to the installation. I can't imagine why a linear progression through a wizard would be preferable.
If you honestly have a hard time installing SuSE, then I just can't imagine what kind of installer you'd find easier. (I guess that's why I don't design installers.)
This article at TheAge disputes whether this object is really a planet.
Uh, so do the articles. None of them claims that this is a planet. All three of them draw comparisons with Pluto, and discuss the nature of the Kuiper belt.
I had another thought. If I remove a chapter from a book, isn't that an abridged version? And then, isn't that a derivative work, which is no longer covered by fair use?
Similarly, if I make a bunch of internal copies, then I want to distribute them under First Sale right, then I must distribute the whole thing (including source) or else it's not just a copy, but a derivative work, and that is disallowed by copyright law + GPL.
Hi. I'd like to build myself a television. I know all the features I want to have (colour, brightness, and contrast controls; coax, RCA, and SVGA inputs; 16:9 aspect ratio; light weight; 35" diagonal). I'm wondering, what approach should I use to build my TV? How do the pros do it?
I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.
If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.
OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...
Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.
For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.
As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.
Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.
Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)
When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.
I have only just barely scratched the surface here. This is a truly vast question you have asked.
Hardy har. How did I know the very first Score:5 article would be a Robocop joke? Well, at least you put some thought into it, and didn't just make the ovbious ED209 reference.
Slashdot Mirror
At best, the problem you describe indicates those architectures use too many callee-save registers in their calling conventions. Having more caller-save registers are a pure win from this perspective.
Bull. They'll find a way to modify the laws to turn the advantage even more to themselves.
I think it was cum-muppets. Sick bastard.
Translation: I used to do real-time programming, but I don't any more. Therefore, I believe nobody else does it any more either.
Exactly what I was thinking. This is totally stupid.
The article describes a microbial fuel cell that is totally different.
Maybe it only needs to generate those gigawatts for a very short time. After all, energy = power x time.
10,000 litres is a puddle. That's only 10 cubic metres of water.
"Samples of tungsten"? Why not just buy a light bulb?
I'm not expert, but I think the key to the slingshot effect is that you always receed from a planet's gravity well at the same speed as you approached, but nobody ever said it had to be the same direction. So, to put it simply, suppose a certain planet is travelling at 100m/s relative to the sun, and you are sneaking up behind it at 120m/s. Relative to the planet, you are approaching at 20m/s. After you pass it, you'll receed at the same speed, 20m/s. If you choose to receed from the planet in the direction it's revolving, then you'll leave at 140m/s relative to the sun, having acquired the additional 40m/s at the expense of the planet's kinetic energy.
Of course, this is a one-dimensional example of a three-dimensional phenomenon, but you get the idea.
Hey, thanks. That's interesting. Too bad the comments are gone. I wonder if it's in the Wayback Machine.
Does anyone have any idea how this "imagine a Beowulf cluster" thing started?
I, for one, think you'd have to try pretty hard to find SuSE's installation difficult. She complains about the problems for newbies, but this is SuSE 8.1 Professional. Yes, it's for professionals.
Having said that, I think the installer is wonderful for newbies. I like the fact that you get a summary (which is like a web page, as Eugenia said), and you can drill down as deep as you want to customize it. If you like the defaults that the installer has chosen, you can click OK and go right to the installation. I can't imagine why a linear progression through a wizard would be preferable.
If you honestly have a hard time installing SuSE, then I just can't imagine what kind of installer you'd find easier. (I guess that's why I don't design installers.)
Not Chile, idjut.
Bravo.
Similarly, if I make a bunch of internal copies, then I want to distribute them under First Sale right, then I must distribute the whole thing (including source) or else it's not just a copy, but a derivative work, and that is disallowed by copyright law + GPL.
Right. Sounds just like monopolistic practices.
Agree on not jumping straight in. Disagree on pseudo-code. That is a waste of time. Properly written code looks like pseudo-code anyway.
Unless I'm greatly mistaken, OGRE is nothing like a 3D modeller. It is a 3D realtime (ie. game) rendering engine.
I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.
If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.
OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...
Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.
For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.
As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.
Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.
Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)
When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.
I have only just barely scratched the surface here. This is a truly vast question you have asked.
Good luck with the project.
Hardy har. How did I know the very first Score:5 article would be a Robocop joke? Well, at least you put some thought into it, and didn't just make the ovbious ED209 reference.