Give them the number to their own store. Most salespeople don't even know it.
Only once did I ever get a salesperson to protest, and when he did I gave him the number to the local Denny's restaurant.
Give them a number. Any number. Make one up if you have to (but creative use of real numbers is encouraged:) but never ever give them your real number.
What companies are doing to evade this law is pretty sickening:
They set up a subsidiary in canada, and call you from there. At 5am. Repeatedly.
Dont like it? Oh, too bad. They're outside US jurisdiction, immune from prosecution.
They're also starting to do this from Mexico. Especially since call centers there can be staffed way cheap (like India).
The really best, most excellent calls are the ones with spoofed caller ID of "911" or the police. When you pick up the phone it turns out to be a sales pitch for fluorescent light bulbs.
If you want a system which isnt affected by worms/virus/security issues at all, you could always use a TRS-80.
definitely safer than OSX.
there's no OS updates to have to fuss about with, either.
They can download all the software they want, surf the web and write their email all on the same system they use for their data analysis without worry and I'm not getting calls or visits to my office saying "Ummmmmmm. I think my system is infected"
You could accomplish the same thing with apple//. The hardware is a lot cheaper too.
i love how grandmothers are the benchmark for usability. if the grandmother is the ruler that UI usability shall be measured by, that means we have to use 75 point fonts for all text as well for grandma's poor eyesight.
I'm with P&T on most of their "Bullshit" episodes, but P&T missed some of the most important points of recycling. You really don't want to be dumping used motor oil, mercury thermometers, and lead-acid car batteries into landfills.
For the biodegradable stuff, fine. Dump it and let it rot. Or burn it as fuel. Whatever. But a lot of stuff isn't biodegradable -- plastics and glass for example.
The chinese economy is strongly linked to the US, the US is china's #1 export partner. Military attacks on your primary source of income doesn't seem terribly smart to me.
Taking out the entire GPS constellation would appear no small task either. It's also a lot of expensive effort on an inexpensive target. Compared to other space projects, GPS is dead cheap. Take out a couple GPS satellites, they're replaced almost instantly and very cheaply. So in the end you've accomplished little.
I think the frightening thing for the US is that they won the cold war by simply outspending the USSR. With China's incredible growth it not many years before the opposite situation could occur.
Could you remind me what "war" the US is currently having with China?
But I have yet to see a true/fully CISC design that is smaller and has lower power requirements than an equivalent pure RISC design. For that matter, I haven't seen a new and true CISC design in ages.
it's wildly popular in the embedded market because it's extremely low power and cheaper than RISC in the same form factor and performance realm.
it's not new (it's 68k ISA). but it proves RISC is not a default win.
as for "new" cisc designs, they are probably out there. microchip's PIC comes close to CISC (it has a small instruction set, but it's not pure load/store and it has no u-op engine). just because you havent seen one doesnt mean they dont exist:)
by your definitions and criteria a 6502 is RISC.:-)
it is interesting to note that in the most recent generations of chips, x86/"cisc" designs tend to be much smaller, lower power, etc. than their "risc" counterparts. take the behemoth alpha 21364 for example.
the big wins in power savings come not from shrinking instruction decode space, but going to new fabrication technologies and materials and other technologies. you get orders of magnitude savings there, versus a few %. pure "risc" designs (sparc, mips, etc) have proven diminishing returns vs effort over the past decade or so.
This isn't the problem you seem to believe -- at least not for a RISC design. A VLIW design, however, is another story entirely. VLIW (ie Itanium) != RISC; VLIW needs massive amounts of cache (and bandwidth).
On a RISC chip, the amount of die size increase due to the instruction cache is negligible compared to the die shrink from reduced instruction decode. And in terms of actual usage, instruction caching is a tiny fraction of the space taken; data cache is (overwhelmingly) the majority holder -- and data takes up the same amount of space reguardless of the chip paradigm.
All modern CPUs have anywhere from 512k of cache to several megabytes. In terms of die space the instruction decode is vanishingly small compared to everything else.
So thank you for confirming that this 'design win' of RISC is no longer significant or even relevant anymore.
And as for your contention about a RISC instruction being very complex compared to a CISC uop... RISC instructions (such as 'add', 'load', 'store', or 'is greater') can't be made more atomic.
Yes they can. uops are like "increment program counter" "emit address out the memory bus" "submit read command to memory bus" "retrieve word from data bus into memory bus register" "transfer word from memory bus register into cpu register" etc.
your typical load/store powerpc or mips or sparc "risc instruction" may decode to 3 or more uops (typical x86 might be 4-6)
uops are _very_ low level, bare metal. RISC instructions are fairly high level abstractions by comparison.
PowerPC never had them afaik. MIPS used to have delay slots but got rid of them, and afaik recent SPARC ditched delay slots too. I would have to say yes, delay slots are really not needed anymore. they are probably considered a liability -- or at the very least archaic.
When you say they did much better, what do you mean? Did the ISA limit the creation of faster processors? Did the ISA limit possible compiler optimizations? Once again, could you point me to a comparison of ISAs?
By better I mean much more successful. They also scaled much higher. Look at how widespread MIPS and PowerPC are, versus SPARC. Look at how high SPARC (didn't) scale, versus PowerPC.
MIPS (and x86, and others) benefited greatly from advances in compiler architecture, as it didn't make the assumptions that SPARC made (eg, that compilers wouldn't get better) and thus didn't dedicate fundamental architectural designs (register windows) to "combating" shortcomings of compilers. it was also a much simpler design overall than SPARC.
also, the enormous register sets of SPARC are vastly underutilized. they're largely a waste. hell, the powerpc register set rarely gets 1/2 utilized under even under the best of situations.
Could you point me to documentation that explains why SPARC's register-windows scheme is harder to implement in todays technologies?
No, because it doesn't exist.
register windows scheme isn't harder to implement. register windows scheme is utterly pointless on modern systems.
register windows assumed these things: 1) function calls are incredibly expensive due to saving/loading registers between calls. 2) task switching is incredibly expensive due to saving/loading registers between task switches. 3) compilers would not get appreciably better.
except that in the long run, experience showed that none of these were real issues -- only imagined ones.
other architectures made fewer assumptions like this and did much better in the long run (mips, powerpc).
This is true of the SPARC too. Infact I think its true of all fixed width instruction ISAs. I understand compilers very rarely need to load 32 or 64bit immediate values into registers.
depends on the code, but it happens far more often than you think. especially if you're dealing with fp code.
try objdump on some binaries. it's a real eye opener.
Addresses can usually be generated using PC relative addressing, no?
sometimes. not always. and don't get me started on PIC code for powerpc -- it's a real mess.
Anyways do post links or point me to documentation that describes the difficulties in implementing the SPARC ISA on todays technologies.
its not difficult -- its pointless. i cant point you to documentation describing the difficulties in implementing the 68k ISA on todays technologies either -- but it's just as relevant.
Most of the world's CPU's are a RISC machine, and a RISC cpu's compiler dispatches the equivalent of a CISC u-op.
er no... CISC uops arent anywhere NEAR as complex as RISC instructions. mips, sparc, ppc, alpha instructions are all VERY complex compared to CISC uops.
and eh, the die space you "win" with a smaller instruction decode stage doesnt make up for the space you lose having to add enormous caches because of the increased bandwidth your RISC instructions take. save a few % in instruction decode and lose tons of % in added cache to make up for it.
besides the fact that die space for instruction decode is tiny these days compared to the multiple execution units, the fpu, cache, etc. instruction decode takes vanishingly small amounts of space. so again, that RISC "win" is no longer existent.
RISC looked very "n3at0" in the late 80s as it appeared CISC was running out of steam, but we learned a lot since then. a lot of the assumptions which were the foundation of RISC design turned out to be not true in the long term.
and heh, if you really get down to it none of the modern "RISC" architectures are really "RISC" by the classic definition. so really, RISC is dead by most definitions of the term. it only lives in uops and maybe the embedded space -- and even that is being eaten up by a growing CISC market (motorola coldfire for example).
doing all optimizations in the compiler would be just dandy if all programs were 100% static and linear.
since they're not, runtime optimizations in hardware need to be done.
you ph.d hardware types want to push all optimizations into the compiler, so it "simplifies the hardware". great. you got itanium. see how well that worked? oh wait, it didnt.
Which brings me back to my point of hardware being forced to do things that the compiler should have been doing in the first place. There's nothing like having to translate each 'input' instruction into multiple real instructions to be executed.
oh great, now you want compilers to emit u-ops to make your life easier. and you hardware guys wonder why we call you unhinged?
Slashdot Mirror
I used to do this to Radio Shack:
:) but never ever give them your real number.
Give them the number to their own store. Most salespeople don't even know it.
Only once did I ever get a salesperson to protest, and when he did I gave him the number to the local Denny's restaurant.
Give them a number. Any number. Make one up if you have to (but creative use of real numbers is encouraged
What companies are doing to evade this law is pretty sickening:
They set up a subsidiary in canada, and call you from there. At 5am. Repeatedly.
Dont like it? Oh, too bad. They're outside US jurisdiction, immune from prosecution.
They're also starting to do this from Mexico. Especially since call centers there can be staffed way cheap (like India).
The really best, most excellent calls are the ones with spoofed caller ID of "911" or the police. When you pick up the phone it turns out to be a sales pitch for fluorescent light bulbs.
The ARM has no fpu, so the x86 will completely trash the ARM in that respect.
You should have bought a gumstix insead. Or maybe a soekris.
The NSLU2 doesnt really have enough CPU for asterisk.
Try a gumstix. Not only is it much faster than a wrt54(g|gs) but you can expand it with whatever interfaces you like.
The MTV of today is completely different from the MTV of the 1980s. The MTV of the 1980s used to actually play music.
If you want to watch a channel that sorta resembles what MTV used to be like 15 years ago (minus adam curry etc) try VH1.
I have a mini and I disagree. Especially with the tiger / dashboard fiasco.
A most excellent recommendation indeed.
If you're really ambitious, you could try This Mac.
Beige box! Looks exactly like a wintel PC! Fool your friends!
And if you need something portable, apple has a solution for you.
If you want a system which isnt affected by worms/virus/security issues at all, you could always use a TRS-80.
//. The hardware is a lot cheaper too.
definitely safer than OSX.
there's no OS updates to have to fuss about with, either.
They can download all the software they want, surf the web and write their email all on the same system they use for their data analysis without worry and I'm not getting calls or visits to my office saying "Ummmmmmm. I think my system is infected"
You could accomplish the same thing with apple
i love how grandmothers are the benchmark for usability. if the grandmother is the ruler that UI usability shall be measured by, that means we have to use 75 point fonts for all text as well for grandma's poor eyesight.
osx is pretty useless without them. at least, you can't view 98% of online content without media player and realplayer.
glass is also incredibly expensive to produce (it takes a lot of energy), as does most refined products (metals etc). recycling is cheaper.
I'm with P&T on most of their "Bullshit" episodes, but P&T missed some of the most important points of recycling. You really don't want to be dumping used motor oil, mercury thermometers, and lead-acid car batteries into landfills.
For the biodegradable stuff, fine. Dump it and let it rot. Or burn it as fuel. Whatever. But a lot of stuff isn't biodegradable -- plastics and glass for example.
HP seems hellbent on self destruction.
First the utterly pointless merger with Compaq.
Then the abandonment of developing HP-PA in favor of developing Itanium.
Then dissolving the Itanium partnership.
Now, inflicting DRM on all their consumer products. Woo hoo, because it worked so fucking well for Sony that Apple ground them to dust.
If I were an HP shareholder, I'd be demanding executives heads on platters about now...
The chinese economy is strongly linked to the US, the US is china's #1 export partner. Military attacks on your primary source of income doesn't seem terribly smart to me.
Taking out the entire GPS constellation would appear no small task either. It's also a lot of expensive effort on an inexpensive target. Compared to other space projects, GPS is dead cheap. Take out a couple GPS satellites, they're replaced almost instantly and very cheaply. So in the end you've accomplished little.
I think the frightening thing for the US is that they won the cold war by simply outspending the USSR. With China's incredible growth it not many years before the opposite situation could occur.
Could you remind me what "war" the US is currently having with China?
What about the new trackerless torrent protocol though? They wouldnt need to run any tracker at all.
The problem is that virtually ALL DRM is like this.
It's a small step for him in a better direction, perhaps, but he hasn't changed his position from reading those remarks.
Yep. He's still an asshole.
But I have yet to see a true/fully CISC design that is smaller and has lower power requirements than an equivalent pure RISC design. For that matter, I haven't seen a new and true CISC design in ages.
:)
Motorola Coldfire
it's wildly popular in the embedded market because it's extremely low power and cheaper than RISC in the same form factor and performance realm.
it's not new (it's 68k ISA). but it proves RISC is not a default win.
as for "new" cisc designs, they are probably out there. microchip's PIC comes close to CISC (it has a small instruction set, but it's not pure load/store and it has no u-op engine). just because you havent seen one doesnt mean they dont exist
by your definitions and criteria a 6502 is RISC. :-)
it is interesting to note that in the most recent generations of chips, x86/"cisc" designs tend to be much smaller, lower power, etc. than their "risc" counterparts. take the behemoth alpha 21364 for example.
the big wins in power savings come not from shrinking instruction decode space, but going to new fabrication technologies and materials and other technologies. you get orders of magnitude savings there, versus a few %. pure "risc" designs (sparc, mips, etc) have proven diminishing returns vs effort over the past decade or so.
This isn't the problem you seem to believe -- at least not for a RISC design. A VLIW design, however, is another story entirely. VLIW (ie Itanium) != RISC; VLIW needs massive amounts of cache (and bandwidth).
On a RISC chip, the amount of die size increase due to the instruction cache is negligible compared to the die shrink from reduced instruction decode. And in terms of actual usage, instruction caching is a tiny fraction of the space taken; data cache is (overwhelmingly) the majority holder -- and data takes up the same amount of space reguardless of the chip paradigm.
All modern CPUs have anywhere from 512k of cache to several megabytes. In terms of die space the instruction decode is vanishingly small compared to everything else.
So thank you for confirming that this 'design win' of RISC is no longer significant or even relevant anymore.
And as for your contention about a RISC instruction being very complex compared to a CISC uop... RISC instructions (such as 'add', 'load', 'store', or 'is greater') can't be made more atomic.
Yes they can. uops are like "increment program counter" "emit address out the memory bus" "submit read command to memory bus" "retrieve word from data bus into memory bus register" "transfer word from memory bus register into cpu register" etc.
your typical load/store powerpc or mips or sparc "risc instruction" may decode to 3 or more uops (typical x86 might be 4-6)
uops are _very_ low level, bare metal. RISC instructions are fairly high level abstractions by comparison.
PowerPC never had them afaik. MIPS used to have delay slots but got rid of them, and afaik recent SPARC ditched delay slots too. I would have to say yes, delay slots are really not needed anymore. they are probably considered a liability -- or at the very least archaic.
When you say they did much better, what do you mean? Did the ISA limit the creation of faster processors? Did the ISA limit possible compiler optimizations? Once again, could you point me to a comparison of ISAs?
By better I mean much more successful. They also scaled much higher. Look at how widespread MIPS and PowerPC are, versus SPARC. Look at how high SPARC (didn't) scale, versus PowerPC.
MIPS (and x86, and others) benefited greatly from advances in compiler architecture, as it didn't make the assumptions that SPARC made (eg, that compilers wouldn't get better) and thus didn't dedicate fundamental architectural designs (register windows) to "combating" shortcomings of compilers. it was also a much simpler design overall than SPARC.
also, the enormous register sets of SPARC are vastly underutilized. they're largely a waste. hell, the powerpc register set rarely gets 1/2 utilized under even under the best of situations.
Could you point me to documentation that explains why SPARC's register-windows scheme is harder to implement in todays technologies?
No, because it doesn't exist.
register windows scheme isn't harder to implement. register windows scheme is utterly pointless on modern systems.
register windows assumed these things:
1) function calls are incredibly expensive due to saving/loading registers between calls.
2) task switching is incredibly expensive due to saving/loading registers between task switches.
3) compilers would not get appreciably better.
except that in the long run, experience showed that none of these were real issues -- only imagined ones.
other architectures made fewer assumptions like this and did much better in the long run (mips, powerpc).
This is true of the SPARC too. Infact I think its true of all fixed width instruction ISAs. I understand compilers very rarely need to load 32 or 64bit immediate values into registers.
depends on the code, but it happens far more often than you think. especially if you're dealing with fp code.
try objdump on some binaries. it's a real eye opener.
Addresses can usually be generated using PC relative addressing, no?
sometimes. not always. and don't get me started on PIC code for powerpc -- it's a real mess.
Anyways do post links or point me to documentation that describes the difficulties in implementing the SPARC ISA on todays technologies.
its not difficult -- its pointless. i cant point you to documentation describing the difficulties in implementing the 68k ISA on todays technologies either -- but it's just as relevant.
Most of the world's CPU's are a RISC machine, and a RISC cpu's compiler dispatches the equivalent of a CISC u-op.
er no... CISC uops arent anywhere NEAR as complex as RISC instructions. mips, sparc, ppc, alpha instructions are all VERY complex compared to CISC uops.
and eh, the die space you "win" with a smaller instruction decode stage doesnt make up for the space you lose having to add enormous caches because of the increased bandwidth your RISC instructions take. save a few % in instruction decode and lose tons of % in added cache to make up for it.
besides the fact that die space for instruction decode is tiny these days compared to the multiple execution units, the fpu, cache, etc. instruction decode takes vanishingly small amounts of space. so again, that RISC "win" is no longer existent.
RISC looked very "n3at0" in the late 80s as it appeared CISC was running out of steam, but we learned a lot since then. a lot of the assumptions which were the foundation of RISC design turned out to be not true in the long term.
and heh, if you really get down to it none of the modern "RISC" architectures are really "RISC" by the classic definition. so really, RISC is dead by most definitions of the term. it only lives in uops and maybe the embedded space -- and even that is being eaten up by a growing CISC market (motorola coldfire for example).
that $1000 is the _bottom_ of the itanium line. $1000 barely gets your foot in the door with itanium. $1000 is _top_ of the amd64 line.
the difference is like night and day.
doing all optimizations in the compiler would be just dandy if all programs were 100% static and linear.
since they're not, runtime optimizations in hardware need to be done.
you ph.d hardware types want to push all optimizations into the compiler, so it "simplifies the hardware". great. you got itanium. see how well that worked? oh wait, it didnt.
Which brings me back to my point of hardware being forced to do things that the compiler should have been doing in the first place. There's nothing like having to translate each 'input' instruction into multiple real instructions to be executed.
oh great, now you want compilers to emit u-ops to make your life easier. and you hardware guys wonder why we call you unhinged?