Modern CPUs "translating instructions into hardware instructions" with a gate maze is essentially the same thing as pulling a wide microcode word from ROM whose bits directly control the logic units.
Only if you ignore the mechanism of how it's done. However, the term "microcode" was created to describe the mechanism, not the result.
Under your definition, it would appear any division of an instruction into multiple suboperations would qualify as microcode. That would presumably include the old-time CPUs that used state machine sequencers made from random flip flops and gates to run multi-step operations.
The end result of those state machines was the same as microcode, and the microcode ROM (which included the next ROM address as part of the word) was logically a form of state machine. However, the word microcode was used to differentiate a specific type of state machine, where the logic functions were encoded in a regular grid-shaped ROM array, from other types of state machines. Modern CISC code translation does not involve ROM encoding, and is not this type of state machine.
People get confused with the way current x86's break apart instructions into microops. That's doesn't make it RISC. That just make it microcoded.
That most certainly does not make it microcoded. Microcode is a set of words encoded in ROM memory that are read out one per clock, whose bits directly control the logic units of a processor. Microcode usually runs sequentially, in a fixed order, may contain subroutines, and is usually not very efficient.
Modern CISC CPUs translate the incoming instructions into a different set of hardware instructions. These instructions are not coded in a ROM, and they can run independently, out of order and concurrently. They are much closer to RISC instructions than to any microcode.
The X86 still contains real microcode to handle the stupid complex instructions from the 80286 era that nobody uses anymore. They usually take many clocks per instruction, and using them is not recommended.
Aren't there laws on the books with serious penalties for unauthorized reception of private radio signals? Why shouldn't the mall owners be busted for this snooping just like they would if they were hacking DirecTV signals?
Actually, that brings up a potential advantage of using algae to produce a significant fraction of worldwide energy needs. The amount of biofuel required would dwarf current global food production, so in the case of major crop failures caused by natural disasters or disease, we would have a large potential source of emergency backup food.
I recently saw an item on TV covering an algae energy startup company. As a stunt they were sharing shotglasses full of green algae water with the host, so maybe Soylent Green *not* made from people would be a possibility.
noted that he did not object to home recording of his television programs Well, he's kind of a special case. If I had a toy train track that opened up a wormhole between my living room and a whole alternate reality, then I wouldn't be very focused on minutia like copyrights either.
Interesting, I never thought of the old Egyption religions as pyramid schemes, but I suppose they were the first too.
Pharaoh to subjects: "Hey, how about you all help me cut and stack about 5 million tons of rock for my mausoleum? Once we're done with that, I'll show you how you can each recruit your own personal crew and have them build similar monuments for yourselves!"
The local flooding is a short-term fluctuation. We're talking about finding enough water to irrigate huge swaths of the western US, which aren't currently growing crops mainly because they don't have enough water. Emptying all of the smaller lakes in Michigan wouldn't make a dent in that problem, and the water levels of the Great Lakes are already a political hot potato without undertaking a massive new diversion project.
The size of the x86 decoder as a percentage of die area has been decreasing ever since the days of the 386. It's now pretty negligible. In return for that, you get a very compact instruction set coding that saves on cache space, thus cutting down on the largest single consumer of real estate on the die.
I notice that the ARM has added a whole alternative instruction set to save on code size, too. So the idea must have some merit.
I don't want to be crass but the disaster in Burma isn't even countable. I know they can do estimates and such but major events like Burma should be accounted, are they? What about Iraq?
IIRC, somewhere in the neighborhood of 200,000 people are born and 100,000 die every day. The Burma disaster and/or the Iraq war would throw off the count by only a few hours. The bigger issue is that the entire count is just a gross estimate.
Besides, whats the fear? Its not like this planet cannot support double that if not more.
Some estimates say that will happen. Then what? What if everyone in the world manages to raise their standard of living to US levels? Then you'd need to find resources at 5X or more the rate we're currently using. Have you checked commodity prices lately?
Hell on my recent 1600 mile trip to and from Ohio I can tell you this, this country is empty in many spots and I am sure it is in others.
The problem is water, without which all that space will stay just as empty as it is now. We're already mining it out of aquifers that are drying up, and we're diverting so much from surface sources that it's causing problems downstream.
Even when it comes to performance, x86 is relatively inferior compared to something like an ARM processor - it's mostly the higher clock speed
I don't believe that. I got a Compaq iPaq PDA a few years back so I could play around with it. I was excited that it had a 200MHz ARM CPU, and I was expecting that it would run with similar performance to a 200MHz Pentium.
I loaded Linux on to the thing and compiled a few test programs. I was highly disappointed to find out that the CPU actually ran with a performance level closer to a 66MHz 486. Live and learn. Well, it turns out that that's the price you pay for having almost no cache and a single ALU with in-order execution. This CPU certainly wasn't defeated by Intel's high clock speeds.
The truth is that, with a very few notable exceptions, OSS is generally crapware that gets abandoned once the project obtains an arbitrary level of usability and all the sexy code has been written.
The vast majority of all proprietary software ever written is also abandoned crapware. The main difference is that you no longer have access to most of it. Old abandoned OSS tends to accumulate on public archives; if you just ignore it, then it won't bother you.
They're probably using a 64-bit number to hold the timestamp. That gives you 1.8e19 discreet time intervals, so you're going to get ridiculous precision, dates ridiculously far into the future, or both. I assume that they went for precision because that arguably has more potential for use in the real world than worrying about files thousands of years into the future.
IIRC, today's PCs have high-resolution timers available that surpass the old 14.318MHz clock chip. If you can't get accurate nanoseconds out of the timers yet, they'll just round the numbers off. No big deal.
BTW, NTFS uses 100ns timestamp granularity, and it was designed when systems were almost 100X slower than today. So it had a similar amount of overkill, but that certainly doesn't seem to have had any negative impact on the acceptance of NTFS.
It doesn't sound objectively any more lame to me than a prefixes like "giga" and "peta". You probably just think it sounds weird because you're not used to it yet.
If you're starting a crusade to clean up the language, why not start with far more egregious problems like all the words that contain the string "ough"?
The problem is that they don't use just powers of two. They mix together odd multiples of 1024, 1048576 and 103741824 in the same program, and then present this mix of incompatible numbers to you in one listing. How many 100 MiB files fit on a 4.38 GiB DVD? You can't tell unless you get out a calculator. (Hint: the answer isn't 43.8).
Nobody cares how many bytes are in a sector. Hard drives use 512 byte sectors, but filesystems use different numbers. Sometimes one filesystem type uses different sized blocks (1024, 4096) based on the size of the media. That's totally irrelevant to the user and just gets tacked into the filesystem overhead along with space for directory entries, timestamps, filenames and security attributes. Some filesystems can even pile multiple small file fragments within a single block, rendering your argument totally invalid. None of these low-level implementation details need to show up in a directory listing, especially if it makes it needlessly impossible to do mental computations on the displayed numbers.
If a group of people are willing to shut down a nuclear power plant in order to get materials for weapons, what is to prevent them from tampering with this detector?
After they open the detector, they wont know if they're supposed to cut the red wire or cut the blue wire.
Um, if what you've heard is true, why have threads been in Unix for a very long time?
In the early 90s, threads were the "next big thing". Around that time Java was being designed, so it ended up oozing in threadedness. Threads were tacked into Unix as an afterthought somewhere around that era to keep up with the latest fads.
Windows NT was also created in those times. Since threads were seen as the way of the future, the design of Windows NT was heavily focused on threads, and that was touted as making the new OS more "modern". There was not a lot of emphasis on process spawning efficiency since it was assumed that an app needing concurrency would create multiple threads rather than spawn processes.
CreateProcess was a heavy, slow operation (at least back then, I don't know about recent Windows kernels); I've verified that myself. Windows also lacked a native fork() call for fast process cloning. It was much more efficient to keep a thread pool around inside an app to handle asynchronous inputs than to spawn processes for them.
And everyone always forgets that the minimum allocation size on a hard disk is 512bytes so it actually makes sense to report the space in powers of 2.
No, it doesn't. All that means is that the capacity is divisible by 2^9 bytes. Since all higher multipliers of capacity have no dependence on 2, it means that 2 is not a useful radix for dealing with drive capacities. In particular, a drive has absolutely zero relationship to the quantities for MiB (1024^2) or GiB (1024^3).
The drive I'm using right now has 30401 logical cylinders and 16065 blocks/cylinder. Those numbers are not even divisible by a single 2, much less powers of 2.
Just because some storage company's marketing departments have now decided otherwise
You mean "now", as in as long as anybody can remember? Because that's how long hard drives have been specified in base 10 by manufacturers. That makes sense, since unlike RAM, the size of a hard drive, based on cylinders and sectors, has nothing to do with the number 2.
Floppy drives have always been specified in an even more insane system than RAM, where "MB" == 1000*1024. That's not base 2 either.
I can't believe that after all these years of hard drives being sold in SI notation, that anybody is surprised by that. It's probably because one single application program, Windows Explorer, happens to confusingly report sizes in pseudo-binary. (Which BTW makes it really hard for people to interpret and work with the displayed numbers properly because of the extra needed math to convert between KiB, MiB and GiB). That's a software bug, not a problem with disk drives or their marketing.
And once he is that sophisticated, what prevents him from downloading [Ubuntu|Fedora|Mandrake|etc] like the rest of us?
When you say "rest of us", you're talking about the 2% of people who are willing to both learn a new OS and live outside of the comfort zone shared by those who use the dominant OS. When introducing computers for the first time to a group of people without much money, why not create a comfort zone that doesn't come with a lifetime of licensing fees?
Why should it matter to some poor kid, just needing a way to afford schoolbooks, what OS his laptop is running?
It won't matter in the short term. But in the long term, the kid will grow up, and he's likely to find that the only OS he learned how to use isn't being offered to adults for free. Then the price difference between the two paths may become rather large relative to his income.
Except in this case, of course, it was the Hamas spokesman on the radio in New York, doing an interview, and expressing his preference for Obama.
Hamas is using reverse psychology. Their entire existence depends on a continual state of conflict. If the conflict were removed, there would be no need for any of their terrorist or military activities, leaving only a political party. If their party were to remain in power, the people that they lead would quickly realize that they are no less corrupt or ineffective than any other Palestinian government has been, and would be voted out of power within a couple of years.
Hamas needs to have an adversary to leverage. McCain would be the one to ensure Hamas' continued existence and influence. That's why they endorese McCain's opponents, knowing that many American voters will have a knee-jerk reaction in the opposite direction, which increases McCain's chances of winning.
Why not charge for the things you love to do such as writing software
Anybody is entitled to try to charge for anything they do. The problem is, some activities are loved by so many people that there's a surplus, so it's hard to charge for it. For example, very few people successfully charge for solving crossword puzzles or drinking beer.
*Writing* software is one of those things that can be fun enough that there is a surplus for many application areas, and some people are just going to do it for free. People who want to charge for the simple act of writing software will just have to deal with that.
This isn't really a threat to software businesses, however, because only a small part of the effort that goes into a commercial software product is the actual writing code. Usually, far more resources go into product research, testing, QA, documentation, marketing, sales, packaging, distribution and support than just writing code. Most of those things aren't very fun and don't face the prospect of having to compete with people who do it for free. Most customers don't have much use for raw code and need to have these additional non-free features included with their software product, so there is money to be made in software even if the monetary value of writing fun code is very low.
Slashdot Mirror
Only if you ignore the mechanism of how it's done. However, the term "microcode" was created to describe the mechanism, not the result.
Under your definition, it would appear any division of an instruction into multiple suboperations would qualify as microcode. That would presumably include the old-time CPUs that used state machine sequencers made from random flip flops and gates to run multi-step operations.
The end result of those state machines was the same as microcode, and the microcode ROM (which included the next ROM address as part of the word) was logically a form of state machine. However, the word microcode was used to differentiate a specific type of state machine, where the logic functions were encoded in a regular grid-shaped ROM array, from other types of state machines. Modern CISC code translation does not involve ROM encoding, and is not this type of state machine.
That most certainly does not make it microcoded. Microcode is a set of words encoded in ROM memory that are read out one per clock, whose bits directly control the logic units of a processor. Microcode usually runs sequentially, in a fixed order, may contain subroutines, and is usually not very efficient.
Modern CISC CPUs translate the incoming instructions into a different set of hardware instructions. These instructions are not coded in a ROM, and they can run independently, out of order and concurrently. They are much closer to RISC instructions than to any microcode.
The X86 still contains real microcode to handle the stupid complex instructions from the 80286 era that nobody uses anymore. They usually take many clocks per instruction, and using them is not recommended.
Aren't there laws on the books with serious penalties for unauthorized reception of private radio signals? Why shouldn't the mall owners be busted for this snooping just like they would if they were hacking DirecTV signals?
Stalinism was also just a bureaucracy gone bad.
I recently saw an item on TV covering an algae energy startup company. As a stunt they were sharing shotglasses full of green algae water with the host, so maybe Soylent Green *not* made from people would be a possibility.
Pharaoh to subjects: "Hey, how about you all help me cut and stack about 5 million tons of rock for my mausoleum? Once we're done with that, I'll show you how you can each recruit your own personal crew and have them build similar monuments for yourselves!"
The local flooding is a short-term fluctuation. We're talking about finding enough water to irrigate huge swaths of the western US, which aren't currently growing crops mainly because they don't have enough water. Emptying all of the smaller lakes in Michigan wouldn't make a dent in that problem, and the water levels of the Great Lakes are already a political hot potato without undertaking a massive new diversion project.
I notice that the ARM has added a whole alternative instruction set to save on code size, too. So the idea must have some merit.
IIRC, somewhere in the neighborhood of 200,000 people are born and 100,000 die every day. The Burma disaster and/or the Iraq war would throw off the count by only a few hours. The bigger issue is that the entire count is just a gross estimate.
Besides, whats the fear? Its not like this planet cannot support double that if not more.Some estimates say that will happen. Then what? What if everyone in the world manages to raise their standard of living to US levels? Then you'd need to find resources at 5X or more the rate we're currently using. Have you checked commodity prices lately?
Hell on my recent 1600 mile trip to and from Ohio I can tell you this, this country is empty in many spots and I am sure it is in others.The problem is water, without which all that space will stay just as empty as it is now. We're already mining it out of aquifers that are drying up, and we're diverting so much from surface sources that it's causing problems downstream.
I don't believe that. I got a Compaq iPaq PDA a few years back so I could play around with it. I was excited that it had a 200MHz ARM CPU, and I was expecting that it would run with similar performance to a 200MHz Pentium.
I loaded Linux on to the thing and compiled a few test programs. I was highly disappointed to find out that the CPU actually ran with a performance level closer to a 66MHz 486. Live and learn. Well, it turns out that that's the price you pay for having almost no cache and a single ALU with in-order execution. This CPU certainly wasn't defeated by Intel's high clock speeds.
The vast majority of all proprietary software ever written is also abandoned crapware. The main difference is that you no longer have access to most of it. Old abandoned OSS tends to accumulate on public archives; if you just ignore it, then it won't bother you.
IIRC, today's PCs have high-resolution timers available that surpass the old 14.318MHz clock chip. If you can't get accurate nanoseconds out of the timers yet, they'll just round the numbers off. No big deal.
BTW, NTFS uses 100ns timestamp granularity, and it was designed when systems were almost 100X slower than today. So it had a similar amount of overkill, but that certainly doesn't seem to have had any negative impact on the acceptance of NTFS.
It doesn't sound objectively any more lame to me than a prefixes like "giga" and "peta". You probably just think it sounds weird because you're not used to it yet.
If you're starting a crusade to clean up the language, why not start with far more egregious problems like all the words that contain the string "ough"?
In keeping with industry practices, maybe they should have rephrased the claim to say: Almost any random hardware is "Ubuntu Capable".
Nobody cares how many bytes are in a sector. Hard drives use 512 byte sectors, but filesystems use different numbers. Sometimes one filesystem type uses different sized blocks (1024, 4096) based on the size of the media. That's totally irrelevant to the user and just gets tacked into the filesystem overhead along with space for directory entries, timestamps, filenames and security attributes. Some filesystems can even pile multiple small file fragments within a single block, rendering your argument totally invalid. None of these low-level implementation details need to show up in a directory listing, especially if it makes it needlessly impossible to do mental computations on the displayed numbers.
After they open the detector, they wont know if they're supposed to cut the red wire or cut the blue wire.
In the early 90s, threads were the "next big thing". Around that time Java was being designed, so it ended up oozing in threadedness. Threads were tacked into Unix as an afterthought somewhere around that era to keep up with the latest fads.
Windows NT was also created in those times. Since threads were seen as the way of the future, the design of Windows NT was heavily focused on threads, and that was touted as making the new OS more "modern". There was not a lot of emphasis on process spawning efficiency since it was assumed that an app needing concurrency would create multiple threads rather than spawn processes.
CreateProcess was a heavy, slow operation (at least back then, I don't know about recent Windows kernels); I've verified that myself. Windows also lacked a native fork() call for fast process cloning. It was much more efficient to keep a thread pool around inside an app to handle asynchronous inputs than to spawn processes for them.
No, it doesn't. All that means is that the capacity is divisible by 2^9 bytes. Since all higher multipliers of capacity have no dependence on 2, it means that 2 is not a useful radix for dealing with drive capacities. In particular, a drive has absolutely zero relationship to the quantities for MiB (1024^2) or GiB (1024^3).
The drive I'm using right now has 30401 logical cylinders and 16065 blocks/cylinder. Those numbers are not even divisible by a single 2, much less powers of 2.
You mean "now", as in as long as anybody can remember? Because that's how long hard drives have been specified in base 10 by manufacturers. That makes sense, since unlike RAM, the size of a hard drive, based on cylinders and sectors, has nothing to do with the number 2.
Floppy drives have always been specified in an even more insane system than RAM, where "MB" == 1000*1024. That's not base 2 either.
I can't believe that after all these years of hard drives being sold in SI notation, that anybody is surprised by that. It's probably because one single application program, Windows Explorer, happens to confusingly report sizes in pseudo-binary. (Which BTW makes it really hard for people to interpret and work with the displayed numbers properly because of the extra needed math to convert between KiB, MiB and GiB). That's a software bug, not a problem with disk drives or their marketing.
When you say "rest of us", you're talking about the 2% of people who are willing to both learn a new OS and live outside of the comfort zone shared by those who use the dominant OS. When introducing computers for the first time to a group of people without much money, why not create a comfort zone that doesn't come with a lifetime of licensing fees?
It won't matter in the short term. But in the long term, the kid will grow up, and he's likely to find that the only OS he learned how to use isn't being offered to adults for free. Then the price difference between the two paths may become rather large relative to his income.
That solution won't save money. Do you have any idea how much it costs to train a dog to safely and effectively handle a firearm?
Hamas is using reverse psychology. Their entire existence depends on a continual state of conflict. If the conflict were removed, there would be no need for any of their terrorist or military activities, leaving only a political party. If their party were to remain in power, the people that they lead would quickly realize that they are no less corrupt or ineffective than any other Palestinian government has been, and would be voted out of power within a couple of years.
Hamas needs to have an adversary to leverage. McCain would be the one to ensure Hamas' continued existence and influence. That's why they endorese McCain's opponents, knowing that many American voters will have a knee-jerk reaction in the opposite direction, which increases McCain's chances of winning.
Anybody is entitled to try to charge for anything they do. The problem is, some activities are loved by so many people that there's a surplus, so it's hard to charge for it. For example, very few people successfully charge for solving crossword puzzles or drinking beer.
*Writing* software is one of those things that can be fun enough that there is a surplus for many application areas, and some people are just going to do it for free. People who want to charge for the simple act of writing software will just have to deal with that.
This isn't really a threat to software businesses, however, because only a small part of the effort that goes into a commercial software product is the actual writing code. Usually, far more resources go into product research, testing, QA, documentation, marketing, sales, packaging, distribution and support than just writing code. Most of those things aren't very fun and don't face the prospect of having to compete with people who do it for free. Most customers don't have much use for raw code and need to have these additional non-free features included with their software product, so there is money to be made in software even if the monetary value of writing fun code is very low.