One comment, other than that I foolishly mixed up EBP and ESP. Hey, they're both just registers to me, I don't care what the software is doing with 'em.;)
Basically, all name changes will happen in the execute stages, but anything that relies on the naming will be stalled in the earlier dependence tracking stages.
The idea would maintain all of its value if you were restricted to use only immediates with the re-mapping instruction. It'd be a static, compile time thing, but you could "execute" it in the re-map stage (presumeably, just before reNAME ing to physical registers), which wouldn't cause stalls (though I shudder to think of the logic for doing that in a 3 or 4 wide machine). But it 's still not a very good idea.:)
Not a bad idea, actually. You'd still have to do the store, in order to maintain correctness, but you could bypass doing the load. Few problems, though. The stack is not accessed soley through push/pop (in fact for local variables it is rarely the case that they are), and you can add/subtract from ebp at will. So you can't completely throw this off on the rename mechanism -- you have to be able to connect those shadow registers with the addresses they are shadowing at execution time. Keeping track of which variables can be shadowed is a problem, for the same reason. That could stall rename on execution...
I suspect by the time you eat the penalty solving these problems would incur, you might be as well off just spilling into your cache.:)
Very good post. But you're wrong on one tiny little thing...
This larger size increases the cache size needed to store the working set of programs, because all integers (and many other data primitives) require a full 64 bits or more.
That's not true. These architectures don't support byte -register- access, but they do support byte -memory- access. So you can still take your 64-bit register containing "42", do a byte store, and use only 1 byte of a cache line. When you load it, it will either zero or sign extend the single byte to the full 64-bits.
However, storing 64-bit pointers does increase the size of cache needed, and this is something that x86-64 will suffer from as well.
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.
That's the whole point of having sufficient registers, isn't it? By having more, you can keep yourself from having to spill registers.
Basically, you have two options -- a) you have to load/store the value from/to memory each time you use it, because you don't have enough registers and b) you keep it in a register, and maybe have to load/store it or another register later due to register pressure.
I have a hard time believing that a) could be more efficient. I have a hard time believing that you could come up with a contrived code sequence that makes a) better without being blatantly unoptomized.
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.
Moving a register to another is usually a one, maybe zero cycle operation. You may have to store it, if its in a caller-save register and you make another call. But again, I have a hard time seeing how passing an argument on the stack -- requiring at least one store and one load, possibly requiring more stores/loads (because you made another call and had to save the register) -- is better than passing in a register -- where you require at minimum 0 stores/loads, possibly more because of subsequent calls -- can be better. I can see how they would be -equal-, but how would it possibly be -worse-? And when an architectural feature has the potential for good gain, and never has negative gain, the only question left is if the area/circuit delay is worth it.
Not that these RISC architectures are perfect. 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.:P
Of course if you had read the article and had a clue, you'd realize that there is no way in hell that this idea will increase program execution speed "several orders of magnitude". Or one order. I'd guess tripling the number of registers would give you 30%, tops. That's 0.03 orders of magnitude, and that's not accounting for all the ways in which this guy's idea would slow down the processor.
Yes, but the point is that in x86 a huge portion of memory accesses are simply loading and storing values on the stack that could have been stored in registers. Granted, these usually end up in cache hits, but that's also more cache pressure (causing other accesses to miss).
It's a legitimate problem, and solving it would increase performance. If you do it right, anyway.
And of coures, a high performance CPU does matter. Granted, a GHz CPU won't help if you're using ferrous-core memory, but with modern memory (DDR, RDRAM) the CPU -can- still be the bottleneck.
Register renaming already does what's being proposed here, but transparently.
Well, not exactly. Renaming takes care of the case where two things write, say, EAX, by allowing both to go with different physical registers. I.E. you don't have to stall because you only have one architected "EAX" register.
However, your program is still limited to only 8 visible values at any instant. So when you need a 9th -thing- to keep around, you have to spill some registers onto the stack. Register renaming doesn't solve this problem.
Yes, he basically invented register renaming, but put it under explicit programmer control. It's a programmer's solution to what hardware has already done, and as was inevitable he doesn't see that he will do more harm than good.
Here's why his idea sucks:
1) Register renaming dependent on the RMC. You can't issue any instructions if there is a POPRMC in the machine until the POPRMC finishes execution. He calls it "a few cycles", but it's much worse than that. You've prevented any new instructions from entering the window until the stack acess is done, preventing any work that -could- have been done in parallel from even being seen. Function call/return overhead is a big deal, and he just kicked it up a notch.
2) His whole problem #3 -- that you can't explicitly access the upper 16 bits of a 32-bit GPR. All I can say is -- thank God! Being a programmer, he probably doesn't realize that being able to address sub-registers is actually a big problem with x86. The whole sub-register-addressing problem causes all kinds of extra dependencies and merge operations. And he wants to make it worse? I think he should be slapped for this idea. x86-64 had the right idea -- you cannot access -just- the upper 32 bits of a GPR, and when you execute a 32-bit instruction that writes a GPR, the upper 32-bits are not preserved. Which is how the RISCy folks have been doing it all along, but hey.
3) This idea requires an extra clock cycle in the front-end, to do the translation from architected to the expanded architected register space, prior to being able to do the architected->physical register translation.
4) Because you still can't address more than 8 registers at a time, you'll be using lots of MOVRMC instructions in order to make the registers you need visible. Ignore how horrible this would make it for people writting assembly ("Okay, so now EAX means GPR 13?") or compilers, this is going to result in a lot of code bloat.
5) Because of 1) and 4), modern superscalar decoders are going to be shot. If you fetch a MOVRMC, followed by POP EAX and POP EBX, you can't decode the second two until -after- you've decode the MOVRMC and written it's values into the map.
Now all this is so that you can save on loads/stores to the stack. Which is great, but at least when those loads and stores are executing, independent instructions can still go. Every RMC-related stall is exactly that -- no following instruction can make progress.
Not that increasing the number of registers in x86 isn't a good idea -- it's just his implementation that sucks. With him being an x86 programmer, I'm surprised he didn't think of the most obvious solution -- just add a prefix byte to extend the size of the register identifiers in the ModR/M and SIB bytes. You get access to ALL GPRs at once (rather than a 8-register window), no extra stalls are required, and your code size only goes up by one byte for instructions that use the extra registers.
I can't help but commend him on his idea being well-thought out. To the best of his knowlege, he tried to address all issues. But that's the problem -- he's a programmer, not a computer architect.
I agree. Though I also don't think the pillars deserve any "conspiracy rating" either. The presence of pillars is a very minor stylistic point that was the only similarity between the scenes. Put a tank/heavily armed guy in the middle, or the tree of evolution on a wall, -something- else, and I'd believe it.:)
What the hell? Of course they have a need for it. Stronger signals take more power, and thus the weaker the signal you can get away with sending, the better. Analog phones are constrained by battery life too, yah?
If automakers had the same attitude you , we'd all still be driving stick shifts
Not exactly a good example, from the standpoint of supporting your point.
There are schools you attend to learn how to drive. Most of it is learning the law, but a not insubstantial portion of it is simply learning how to operate the vehicle. It takes time and effort to learn to drive, and the automatic transmission did not fundamentally change that fact. It made it easier to drive, but not so easy that it doesn't still take education to do it.
Similarly, the switch from DOS to Win95 didn't change the fact that when my grandmother sits down at a computer she isn't going to have any clue what to do with it unless someone is there to explain it step by step.
Engineers attempt to make computers and software easier to use all the time. The fact that they have failed to reduce the interface to the computer to a single red button labeled "Do It" is not the result of some twisted desire to keep computing out of the hands of the common masses. It's because general purpose computer and simple, toaster-like interface are fundamentally at odds.
Is the point clear? That while it is always good to make computers easier to use, they will never be so easy that you can just sit down at one, never having seen a computer before, and use it competently. You have to give.
So while I can appreciate the desire to see more work done on interfaces, I can't agree with your sentiment that it is a "fallacy that people MUST invest time in order to learn how to use their machines". I can only imagine how that must have gone, when you got your first automatic transmission vehicle. "I thought this automatic transmission was supposed to make driving the car easy! I still have to operate all these levers, pedals, and wheels! Why can't you damn techno-elitists just make it so the car takes me where I want to go?":)
Well, considering that you couldn't really -do- any of that cool stuff in the States until recently, it may be more of a case of "technological lag" than "cultural difference". People in Europe obviously only used their phones as phones before neat data services became available. I imagine that once there becomes a critical mass of data-enabled devices out there, then you'll start seeing these services used more commonly.
Well, I hate to break it to you, since you seem so hopeful and all, but life just ain't that nice.
You really think there isn't one/.'er who lives in Fritz Holling's District and wouldn't have mailed his fat, Disney-whored ass a few dozen times? You really think a few more letters would make him change his ways? Hell no. The bad politicians are not going to not be bad just because they get letters from good people. Until they start actually losing elections over being corporate whores will the message be paid heed.
Not that violence is the answer, mind. Just keep replacing your leaders until the people who want to lead learn that the only way to stay a leader is by actually listening to their voters. And that's pretty tough to do, because that "actually listening" part is so hard to get a good grasp on.
Almost. In this situation, I don't believe that DRM should be protected by anti-circumvention laws either.
You know, I was thinking that also, I just never mentioned it specifically. My assumption was that because the legal basis for preventing circumvention was preventing illegal copying (ie. copyright), anti-circumvention laws would be thrown away. My bad for not spelling that out.
But that may not always remain true - the Digital Rights Management crowd are agitating to get control of system design, because all your bits are belong to them and they want to keep it that way. Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
For that to actually happen, it requires essentially the entire destruction of general-purpose computers. Everything would have to be encrypted, and nothing would work with anything else that wasn't encrypted. Being able to take arbitrary bytes -you- made and run them on a turing-complete device has to be essentially impossible. That's the only way to stop someone from finding something that can be tricked by simulation and simulating it. That said, it can certainly be made very difficult to do much easier.
As a crypto geek, I've got mixed feelings about this - I'd like to be able to write an encrypted voice telephony or video conferencing system that not only couldn't be eavesdropped on, but also couldn't be wiretapped by a virus stealing the data path.
I understand. But what you want is possible -- you want the transaction to be secure in the middle. I.e.: from the input to the recording device to the output on a display device. Someone who was watching the display device could, if they so wished, make a non-encrypted copy of the transmission to send to whomever they liked. You, being a humane person, assume that both sides of the conversation -trust- each other, and thus only need to prevent others from getting to the data.
What these lunatics want is for a situation where you, the intended recipient, are untrusted and unable to copy the communication. The reason I call them lunatics is that you have to invent entirely new technology virtually from scratch simply because we've never even considered how to prevent that in any device that's was made before twenty years ago or so. The assumption that underlined that fact, was that when you send someone a secret message, they can do whatever they want with it once they receive it. Sure, there have always been people who wanted to -stop- people from being able to do that. Early composers complained of their sheet music being copied illegally. But those people were sane, because they merely wanted the copying to be illegal. These people are insane, because they want the copying to be impossible.
It's part of the right to create a product and sell it. The only time that right is not allowed is when, after having created and sold the item commercially, the said thing becomes illegal to sell.
Or if the thing was already illegal, of course. I don't think anyone has ever sold a Baby Blender, but that doesn't mean it wouldn't be illegal.:P
But that's not the point. He didn't say they shouldn't have the right to sell the product -- he asked why does not giving them copyrights for those products take away their right to make them? He saying what if it were still perfectly legal to make a DRM-device that could not be legally circumvented, but the content delivered in such a way could not be protected by copyright? They could still -make- it, they just wouldn't get one benefit under the law for it.
And this is not as radical as it sounds, either. Copyright is not an inherent right, but is in fact a bargain between the people and the producers of art, presided by the state. The producer get a monopoly on reproduction of their work, and in counterbalance the people get a set of rights called "fair use".
If the entertainment industry doesn't want to hold up its end of the bargain by letting us exercise our rights, then they don't get theirs.
Either we both can do whatever we want, or we both have to abide by some rules. They can still sell their DRM devices, but they won't get legal protection above and beyond.
Which if you ask me is how it should be. Can you think of another industry (other than software) where the seller has more rights than the consumer?
Granted it was a nice gesture, but let me play devils advocate here.
You do a nice job, except you try to make the point that he's not sincere because he isn't doing something useful. This fails because if he's sincere, what he's doing is useful. That's circular logic.
Of course my argument relies on the eventuality that the bill could be useful. But I think it can. What does he get now that he wouldn't get before? He gets prolonged public exposure for the ideas in his bill. It gets stories written about a bill that wants to "protect your fair use rights". Rights that people may not have realized are being taken away, because they've only thought of it in terms of piracy. It gives a chance for tech companies to come out in favor of the bill, and in doing so give others the courage to do likewise. With any luck, it will become a medium-sized campaign issue, meaning exposure all the way through the campaign (and maybe winning a few more seats for possible supporters of the law). When the next session opens, he or someone else can raise the issue again without it being a surprise. There'll be a large block of popular and corporate support for the bill from the moment it is proposed.
Oh, it also gets Boucher a lot of good press just prior to his campaign. I can't imagine that he minds this. Yet I don't think that's a bad thing at all, unless he's only doing it for that reason. But that depends on knowing whether he would do it just for the press, even if doing it had no value, and we can't answer that. Since proposing the bill now is useful, I'll give him the benefit of the doubt and presume that's at least part of why he's doing it.
Not that I mind a good batch of cynicism, I just don't want to let it blind me to someone who may in fact be on my side.
You're absolutely right. I perhaps should have said "The MS EULA states that if you don't accept it, you can't use the software." The validity of EULAs has always been in question. I wasn't commenting so much on their legality as what the actual -contents- of the licenses are, and how that makes them fundamentally different.
The bill doesn't ban licenses on software, it bans the EULA as the word means today -- a license that pops up during installation, after you've bought the product and brought it home.
In short, it does exactly what you want -- it gets rid of the crap license you don't like, but keeps the ability to have the all-important disclaimer.
No. The GPL is not in any way an EULA. If you want to use the software, the GPL does nothing. Accepting the GPL or not has no effect whatsoever on your use of the software. If you don't accept the MS EULA, you can't use the software. With the GPL, it doesn't matter. This of course doesn't include making derivative works from or distributing. These are not usually considered End User uses, because they are prohibited by copyright, not by a EULA. If no EULA existed, you still wouldn't be able to modify or distribute a program.
The GPL grants rights to modify and distribute, and yes there are terms for that, but that doesn't make it an EULA. It's as much an EULA as the contracts Microsoft presents when they grant someone access to -their- source code, and believe me they don't stick that in a little window with an "OK" button.:)
That's the deal -- the GPL is a -license- but not an End User License Agreement.
I agree that you don't have the right to actually make money. But, and I think you expressed this in your text as well, I do belive one has the right to attempt to make money. Would you agree that this is a right? If so, do you belive that it is less of a right, more of a right, or equal to the right to free speach?
Well, that depends on how you define it. "The right to attempt to profit" is not, per se, what I'm talking about. But if you take the right to own and control private property, and to enter into contracts, and to speak freely, then you have what it takes to attempt to make money. Personally, those rights don't mean as much to me as free speech, but without them free speech is difficult to maintain. Therefore, for the purposes of our discussion, I'll treat them as equal.
Now that I know more about the situation, I can address your concerns better, but hopefully without having to get so specific that the logic wouldn't apply elsewhere.
So we have a situation where the protestors, upset with the government, asked entertainers to not come to the city. I'm presuming they were successfull in convincing the entertainers not to come. I'm presuming they didn't threaten the entertainers (I figure you would have mentioned such a salient point), but presented their complaints and asked them not to come -- in effect, joining their protest.
At this point, I honestly can't see what right of the local business was being violated. An entertainer heard some speech and decided not to come to the city of their own free will. Yes, the arts group lost the business of that entertainer, but the arts group didn't have the "right" to have that business. They had the right to try to aquire the business of the entertainer, but similarly the entertainer has the right to decline. The business's freedom to control their property wasn't violated (the protestors didn't physically prevent the entertainer from using the businesses facilities), nor was their right to enter into contracts (the entertainer simply exercised their right to not enter contracts).
In general, people have the right to speak. People who hear that speech may take an action as a result, and some of those actions may mean less money for some businesses. There is no right being violated here, because those businesses didn't have a "right" to any of that money they didn't get. People who work for that company may lose their job, which sucks, but they didn't have a "right" to have that particular job.
In this specific example, the business certainly can impact their government in ways that a common citizen can't. Local governments care about small, local businesses (at least in as much as appearing to do so is good for their re-elections, but I digress). "Your policies are hurting our business" is a form of free speech that local representatives will at least listen to. Also, could they not have spoke to the entertainers and tried to convince them to come despite the protests? I'll assume they did (they would be fools not to), and failed.
Oh well.
One may not have any sympathy for the businesses themselves, but those businesses employ people who have the right to try and earn a living, and, to me that right is being directly impacted.
How was their attempt to make money impacted? Was their phoneline cut so they could not contact any entertainers? Were their doors blocked so they couldn't hold concerts? Were the entertainers threatened so that they feared to perform in the city? The only thing I see being impacted was their success at making money, something which is not a right.
Yes, I feel sympathy for small businesses and people who lose their jobs. But my sympathy for their plight has no effect on whether I perceive their rights to be violated, and thus on whether I think the protestors should have had their rights reduced.
Perhaps that's what your feeling? That the business losing out in a situation largely out of control seems unfair? I'll agree that it appears somewhat unfair to me. But the entertainers didn't think it was unfair; they chose not to go to that city. Since it was their action that actually deprived the arts group of money, I'll defer to their judgement. That's their right. You can't restrict free speech because of fairness on the supposition that reducing the speech will eliminate the unfair actions.
Slashdot Mirror
One comment, other than that I foolishly mixed up EBP and ESP. Hey, they're both just registers to me, I don't care what the software is doing with 'em. ;)
:)
Basically, all name changes will happen in the execute stages, but anything that relies on the naming will be stalled in the earlier dependence tracking stages.
The idea would maintain all of its value if you were restricted to use only immediates with the re-mapping instruction. It'd be a static, compile time thing, but you could "execute" it in the re-map stage (presumeably, just before reNAME ing to physical registers), which wouldn't cause stalls (though I shudder to think of the logic for doing that in a 3 or 4 wide machine). But it 's still not a very good idea.
Not a bad idea, actually. You'd still have to do the store, in order to maintain correctness, but you could bypass doing the load. Few problems, though. The stack is not accessed soley through push/pop (in fact for local variables it is rarely the case that they are), and you can add/subtract from ebp at will. So you can't completely throw this off on the rename mechanism -- you have to be able to connect those shadow registers with the addresses they are shadowing at execution time. Keeping track of which variables can be shadowed is a problem, for the same reason. That could stall rename on execution...
:)
I suspect by the time you eat the penalty solving these problems would incur, you might be as well off just spilling into your cache.
Very good post. But you're wrong on one tiny little thing...
This larger size increases the cache size needed to store the working set of programs, because all integers (and many other data primitives) require a full 64 bits or more.
That's not true. These architectures don't support byte -register- access, but they do support byte -memory- access. So you can still take your 64-bit register containing "42", do a byte store, and use only 1 byte of a cache line. When you load it, it will either zero or sign extend the single byte to the full 64-bits.
However, storing 64-bit pointers does increase the size of cache needed, and this is something that x86-64 will suffer from as well.
Why do I see M. Butterfly II written all over this?
;)
Because you're a perv?
Okay, but 30% is still only 0.15 binary orders of magnitude. :)
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.
:P
That's the whole point of having sufficient registers, isn't it? By having more, you can keep yourself from having to spill registers.
Basically, you have two options -- a) you have to load/store the value from/to memory each time you use it, because you don't have enough registers and b) you keep it in a register, and maybe have to load/store it or another register later due to register pressure.
I have a hard time believing that a) could be more efficient. I have a hard time believing that you could come up with a contrived code sequence that makes a) better without being blatantly unoptomized.
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.
Moving a register to another is usually a one, maybe zero cycle operation. You may have to store it, if its in a caller-save register and you make another call. But again, I have a hard time seeing how passing an argument on the stack -- requiring at least one store and one load, possibly requiring more stores/loads (because you made another call and had to save the register) -- is better than passing in a register -- where you require at minimum 0 stores/loads, possibly more because of subsequent calls -- can be better. I can see how they would be -equal-, but how would it possibly be -worse-? And when an architectural feature has the potential for good gain, and never has negative gain, the only question left is if the area/circuit delay is worth it.
Not that these RISC architectures are perfect. 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.
Of course if you had read the article and had a clue, you'd realize that there is no way in hell that this idea will increase program execution speed "several orders of magnitude". Or one order. I'd guess tripling the number of registers would give you 30%, tops. That's 0.03 orders of magnitude, and that's not accounting for all the ways in which this guy's idea would slow down the processor.
Yes, but the point is that in x86 a huge portion of memory accesses are simply loading and storing values on the stack that could have been stored in registers. Granted, these usually end up in cache hits, but that's also more cache pressure (causing other accesses to miss).
It's a legitimate problem, and solving it would increase performance. If you do it right, anyway.
And of coures, a high performance CPU does matter. Granted, a GHz CPU won't help if you're using ferrous-core memory, but with modern memory (DDR, RDRAM) the CPU -can- still be the bottleneck.
Register renaming already does what's being proposed here, but transparently.
:P
Well, not exactly. Renaming takes care of the case where two things write, say, EAX, by allowing both to go with different physical registers. I.E. you don't have to stall because you only have one architected "EAX" register.
However, your program is still limited to only 8 visible values at any instant. So when you need a 9th -thing- to keep around, you have to spill some registers onto the stack. Register renaming doesn't solve this problem.
His idea would, but it's still a stupid idea.
Yes, he basically invented register renaming, but put it under explicit programmer control. It's a programmer's solution to what hardware has already done, and as was inevitable he doesn't see that he will do more harm than good.
Here's why his idea sucks:
1) Register renaming dependent on the RMC. You can't issue any instructions if there is a POPRMC in the machine until the POPRMC finishes execution. He calls it "a few cycles", but it's much worse than that. You've prevented any new instructions from entering the window until the stack acess is done, preventing any work that -could- have been done in parallel from even being seen. Function call/return overhead is a big deal, and he just kicked it up a notch.
2) His whole problem #3 -- that you can't explicitly access the upper 16 bits of a 32-bit GPR. All I can say is -- thank God! Being a programmer, he probably doesn't realize that being able to address sub-registers is actually a big problem with x86. The whole sub-register-addressing problem causes all kinds of extra dependencies and merge operations. And he wants to make it worse? I think he should be slapped for this idea. x86-64 had the right idea -- you cannot access -just- the upper 32 bits of a GPR, and when you execute a 32-bit instruction that writes a GPR, the upper 32-bits are not preserved. Which is how the RISCy folks have been doing it all along, but hey.
3) This idea requires an extra clock cycle in the front-end, to do the translation from architected to the expanded architected register space, prior to being able to do the architected->physical register translation.
4) Because you still can't address more than 8 registers at a time, you'll be using lots of MOVRMC instructions in order to make the registers you need visible. Ignore how horrible this would make it for people writting assembly ("Okay, so now EAX means GPR 13?") or compilers, this is going to result in a lot of code bloat.
5) Because of 1) and 4), modern superscalar decoders are going to be shot. If you fetch a MOVRMC, followed by POP EAX and POP EBX, you can't decode the second two until -after- you've decode the MOVRMC and written it's values into the map.
Now all this is so that you can save on loads/stores to the stack. Which is great, but at least when those loads and stores are executing, independent instructions can still go. Every RMC-related stall is exactly that -- no following instruction can make progress.
Not that increasing the number of registers in x86 isn't a good idea -- it's just his implementation that sucks. With him being an x86 programmer, I'm surprised he didn't think of the most obvious solution -- just add a prefix byte to extend the size of the register identifiers in the ModR/M and SIB bytes. You get access to ALL GPRs at once (rather than a 8-register window), no extra stalls are required, and your code size only goes up by one byte for instructions that use the extra registers.
I can't help but commend him on his idea being well-thought out. To the best of his knowlege, he tried to address all issues. But that's the problem -- he's a programmer, not a computer architect.
I agree. Though I also don't think the pillars deserve any "conspiracy rating" either. The presence of pillars is a very minor stylistic point that was the only similarity between the scenes. Put a tank/heavily armed guy in the middle, or the tree of evolution on a wall, -something- else, and I'd believe it. :)
What the hell? Of course they have a need for it. Stronger signals take more power, and thus the weaker the signal you can get away with sending, the better. Analog phones are constrained by battery life too, yah?
If automakers had the same attitude you , we'd all still be driving stick shifts
:)
Not exactly a good example, from the standpoint of supporting your point.
There are schools you attend to learn how to drive. Most of it is learning the law, but a not insubstantial portion of it is simply learning how to operate the vehicle. It takes time and effort to learn to drive, and the automatic transmission did not fundamentally change that fact. It made it easier to drive, but not so easy that it doesn't still take education to do it.
Similarly, the switch from DOS to Win95 didn't change the fact that when my grandmother sits down at a computer she isn't going to have any clue what to do with it unless someone is there to explain it step by step.
Engineers attempt to make computers and software easier to use all the time. The fact that they have failed to reduce the interface to the computer to a single red button labeled "Do It" is not the result of some twisted desire to keep computing out of the hands of the common masses. It's because general purpose computer and simple, toaster-like interface are fundamentally at odds.
Is the point clear? That while it is always good to make computers easier to use, they will never be so easy that you can just sit down at one, never having seen a computer before, and use it competently. You have to give.
So while I can appreciate the desire to see more work done on interfaces, I can't agree with your sentiment that it is a "fallacy that people MUST invest time in order to learn how to use their machines". I can only imagine how that must have gone, when you got your first automatic transmission vehicle. "I thought this automatic transmission was supposed to make driving the car easy! I still have to operate all these levers, pedals, and wheels! Why can't you damn techno-elitists just make it so the car takes me where I want to go?"
Well, considering that you couldn't really -do- any of that cool stuff in the States until recently, it may be more of a case of "technological lag" than "cultural difference". People in Europe obviously only used their phones as phones before neat data services became available. I imagine that once there becomes a critical mass of data-enabled devices out there, then you'll start seeing these services used more commonly.
The upshot is that the CDMA phone uses just enough transmit power to be received by the base station, and no more. Hence, longer battery life.
Phones have been able to do that since the analog days, and thus isn't a particularly impressive feature.
Bandwidth utilization is of course very nice, though.
Well, I hate to break it to you, since you seem so hopeful and all, but life just ain't that nice.
/.'er who lives in Fritz Holling's District and wouldn't have mailed his fat, Disney-whored ass a few dozen times? You really think a few more letters would make him change his ways? Hell no. The bad politicians are not going to not be bad just because they get letters from good people. Until they start actually losing elections over being corporate whores will the message be paid heed.
You really think there isn't one
Not that violence is the answer, mind. Just keep replacing your leaders until the people who want to lead learn that the only way to stay a leader is by actually listening to their voters. And that's pretty tough to do, because that "actually listening" part is so hard to get a good grasp on.
Er, okay, I actually said the opposite. Maybe I thought of it too late... Bleh.
Almost. In this situation, I don't believe that DRM should be protected by anti-circumvention laws either.
You know, I was thinking that also, I just never mentioned it specifically. My assumption was that because the legal basis for preventing circumvention was preventing illegal copying (ie. copyright), anti-circumvention laws would be thrown away. My bad for not spelling that out.
But that may not always remain true - the Digital Rights Management crowd are agitating to get control of system design, because all your bits are belong to them and they want to keep it that way. Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
For that to actually happen, it requires essentially the entire destruction of general-purpose computers. Everything would have to be encrypted, and nothing would work with anything else that wasn't encrypted. Being able to take arbitrary bytes -you- made and run them on a turing-complete device has to be essentially impossible. That's the only way to stop someone from finding something that can be tricked by simulation and simulating it. That said, it can certainly be made very difficult to do much easier.
As a crypto geek, I've got mixed feelings about this - I'd like to be able to write an encrypted voice telephony or video conferencing system that not only couldn't be eavesdropped on, but also couldn't be wiretapped by a virus stealing the data path.
I understand. But what you want is possible -- you want the transaction to be secure in the middle. I.e.: from the input to the recording device to the output on a display device. Someone who was watching the display device could, if they so wished, make a non-encrypted copy of the transmission to send to whomever they liked. You, being a humane person, assume that both sides of the conversation -trust- each other, and thus only need to prevent others from getting to the data.
What these lunatics want is for a situation where you, the intended recipient, are untrusted and unable to copy the communication. The reason I call them lunatics is that you have to invent entirely new technology virtually from scratch simply because we've never even considered how to prevent that in any device that's was made before twenty years ago or so. The assumption that underlined that fact, was that when you send someone a secret message, they can do whatever they want with it once they receive it. Sure, there have always been people who wanted to -stop- people from being able to do that. Early composers complained of their sheet music being copied illegally. But those people were sane, because they merely wanted the copying to be illegal. These people are insane, because they want the copying to be impossible.
It's part of the right to create a product and sell it. The only time that right is not allowed is when, after having created and sold the item commercially, the said thing becomes illegal to sell.
:P
Or if the thing was already illegal, of course. I don't think anyone has ever sold a Baby Blender, but that doesn't mean it wouldn't be illegal.
But that's not the point. He didn't say they shouldn't have the right to sell the product -- he asked why does not giving them copyrights for those products take away their right to make them? He saying what if it were still perfectly legal to make a DRM-device that could not be legally circumvented, but the content delivered in such a way could not be protected by copyright? They could still -make- it, they just wouldn't get one benefit under the law for it.
And this is not as radical as it sounds, either. Copyright is not an inherent right, but is in fact a bargain between the people and the producers of art, presided by the state. The producer get a monopoly on reproduction of their work, and in counterbalance the people get a set of rights called "fair use".
If the entertainment industry doesn't want to hold up its end of the bargain by letting us exercise our rights, then they don't get theirs.
Either we both can do whatever we want, or we both have to abide by some rules. They can still sell their DRM devices, but they won't get legal protection above and beyond.
Which if you ask me is how it should be. Can you think of another industry (other than software) where the seller has more rights than the consumer?
Granted it was a nice gesture, but let me play devils advocate here.
You do a nice job, except you try to make the point that he's not sincere because he isn't doing something useful. This fails because if he's sincere, what he's doing is useful. That's circular logic.
Of course my argument relies on the eventuality that the bill could be useful. But I think it can. What does he get now that he wouldn't get before? He gets prolonged public exposure for the ideas in his bill. It gets stories written about a bill that wants to "protect your fair use rights". Rights that people may not have realized are being taken away, because they've only thought of it in terms of piracy. It gives a chance for tech companies to come out in favor of the bill, and in doing so give others the courage to do likewise. With any luck, it will become a medium-sized campaign issue, meaning exposure all the way through the campaign (and maybe winning a few more seats for possible supporters of the law). When the next session opens, he or someone else can raise the issue again without it being a surprise. There'll be a large block of popular and corporate support for the bill from the moment it is proposed.
Oh, it also gets Boucher a lot of good press just prior to his campaign. I can't imagine that he minds this. Yet I don't think that's a bad thing at all, unless he's only doing it for that reason. But that depends on knowing whether he would do it just for the press, even if doing it had no value, and we can't answer that. Since proposing the bill now is useful, I'll give him the benefit of the doubt and presume that's at least part of why he's doing it.
Not that I mind a good batch of cynicism, I just don't want to let it blind me to someone who may in fact be on my side.
You're absolutely right. I perhaps should have said "The MS EULA states that if you don't accept it, you can't use the software." The validity of EULAs has always been in question. I wasn't commenting so much on their legality as what the actual -contents- of the licenses are, and how that makes them fundamentally different.
The bill doesn't ban licenses on software, it bans the EULA as the word means today -- a license that pops up during installation, after you've bought the product and brought it home.
In short, it does exactly what you want -- it gets rid of the crap license you don't like, but keeps the ability to have the all-important disclaimer.
No. The GPL is not in any way an EULA. If you want to use the software, the GPL does nothing. Accepting the GPL or not has no effect whatsoever on your use of the software. If you don't accept the MS EULA, you can't use the software. With the GPL, it doesn't matter. This of course doesn't include making derivative works from or distributing. These are not usually considered End User uses, because they are prohibited by copyright, not by a EULA. If no EULA existed, you still wouldn't be able to modify or distribute a program.
:)
The GPL grants rights to modify and distribute, and yes there are terms for that, but that doesn't make it an EULA. It's as much an EULA as the contracts Microsoft presents when they grant someone access to -their- source code, and believe me they don't stick that in a little window with an "OK" button.
That's the deal -- the GPL is a -license- but not an End User License Agreement.
I agree that you don't have the right to actually make money. But, and I think you expressed this in your text as well, I do belive one has the right to attempt to make money. Would you agree that this is a right? If so, do you belive that it is less of a right, more of a right, or equal to the right to free speach?
Well, that depends on how you define it. "The right to attempt to profit" is not, per se, what I'm talking about. But if you take the right to own and control private property, and to enter into contracts, and to speak freely, then you have what it takes to attempt to make money. Personally, those rights don't mean as much to me as free speech, but without them free speech is difficult to maintain. Therefore, for the purposes of our discussion, I'll treat them as equal.
Now that I know more about the situation, I can address your concerns better, but hopefully without having to get so specific that the logic wouldn't apply elsewhere.
So we have a situation where the protestors, upset with the government, asked entertainers to not come to the city. I'm presuming they were successfull in convincing the entertainers not to come. I'm presuming they didn't threaten the entertainers (I figure you would have mentioned such a salient point), but presented their complaints and asked them not to come -- in effect, joining their protest.
At this point, I honestly can't see what right of the local business was being violated. An entertainer heard some speech and decided not to come to the city of their own free will. Yes, the arts group lost the business of that entertainer, but the arts group didn't have the "right" to have that business. They had the right to try to aquire the business of the entertainer, but similarly the entertainer has the right to decline. The business's freedom to control their property wasn't violated (the protestors didn't physically prevent the entertainer from using the businesses facilities), nor was their right to enter into contracts (the entertainer simply exercised their right to not enter contracts).
In general, people have the right to speak. People who hear that speech may take an action as a result, and some of those actions may mean less money for some businesses. There is no right being violated here, because those businesses didn't have a "right" to any of that money they didn't get. People who work for that company may lose their job, which sucks, but they didn't have a "right" to have that particular job.
In this specific example, the business certainly can impact their government in ways that a common citizen can't. Local governments care about small, local businesses (at least in as much as appearing to do so is good for their re-elections, but I digress). "Your policies are hurting our business" is a form of free speech that local representatives will at least listen to. Also, could they not have spoke to the entertainers and tried to convince them to come despite the protests? I'll assume they did (they would be fools not to), and failed.
Oh well.
One may not have any sympathy for the businesses themselves, but those businesses employ people who have the right to try and earn a living, and, to me that right is being directly impacted.
How was their attempt to make money impacted? Was their phoneline cut so they could not contact any entertainers? Were their doors blocked so they couldn't hold concerts? Were the entertainers threatened so that they feared to perform in the city? The only thing I see being impacted was their success at making money, something which is not a right.
Yes, I feel sympathy for small businesses and people who lose their jobs. But my sympathy for their plight has no effect on whether I perceive their rights to be violated, and thus on whether I think the protestors should have had their rights reduced.
Perhaps that's what your feeling? That the business losing out in a situation largely out of control seems unfair? I'll agree that it appears somewhat unfair to me. But the entertainers didn't think it was unfair; they chose not to go to that city. Since it was their action that actually deprived the arts group of money, I'll defer to their judgement. That's their right. You can't restrict free speech because of fairness on the supposition that reducing the speech will eliminate the unfair actions.
This is an interesting discussion.