Hi, what's it like in 2005? Over here in 2011, we have Thumb-2 as the standard instruction set for newly compiled ARM code (the Cortex-M series only supports it, The Cortex-A series supports ARM for legacy compatibility). Unlike Thumb-1, Thumb-2 can encode the entire ARM instruction set, with most instructions being 16 bits and some being 32. If you're using the unified assembly syntax, you can switch between the two with an assembler flag: the assembly code is the same because they're just two encodings of the same instruction set.
There's very little difference between the two instruction sets that makes one more power efficient than the other
There are two aspects of an instruction set that effect power consumption. One is density: how much instruction cache do you need for a given algorithm. ARM does about as well as i386 here, and Thumb-2 does better (typically about 20% smaller code than x86). Smaller instruction cache means less power consumption. The other is decoder complexity: how many transistors do you need to decode the instructions. x86 instructions are somewhere between 1 and 15 bytes, and the encoding scheme is highly non-othrogonal, so the logic required to decode them is very complex. ARM instructions are 32 bits and have fixed encoding and opcode fields, so you need a tiny handful of transistors to decode them. Thumb-2 instructions are variable length, but only come in two sizes (16 and 32 bits) and are only slightly more complex to decode. The micro-op decoder on a modern x86 chip is about as complex as the Thumb-2 decoder...
x86-64 can do register-memory type operands which is much more efficient
This thread is full of strange definitions. Requiring the CPU to do alias analysis, in hardware, at run time, is certainly not what I would call 'efficient', but sure, let's go with that definition for now...
Early ARM chips didn't have an integer divide instruction because it took up to 12 cycles[1] to perform integer division and you could get the same performance without complicating the pipeline without it. Integer division is often cited as one of the main reasons why RISC had problems, because newer techniques reduced the number of cycles required to perform integer division, so newer CISC chips just used those in place of the old microcoded loops, while RISC code got no benefit unless the instruction set was extended and the code recompiled. Modern RISC chips - including ARM - do have integer division instructions though, and compilers use them, so this is something of a moot point.
[1] It was a variable number, which made life very difficult for hardware designers. One of the benefits early RISC architectures had was the fact that their instructions took the same length of time to execute, so the pipeline could be very simple.
It's worth noting that with the Cortex A9 and newer, ARM has done a lot to standardise things. For example, interrupt controllers now have a standard well-defined interface. This means that once you have one Cortex A9 SoC working, getting the next working is about as hard as getting a new x86 laptop working: you may need device drivers for the GPU and a few other things, but the core functionality will be the same.
The instruction decoder is such an absurdly tiny part of a modern CPU that it really doesn't matter.
Not true. It is quite a small part, but it is the part that you can not turn off or put in a low power state as long as the CPU is doing anything. This is why it becomes important on low-power systems: it's a constant power drain. Big FPUs and SIMD units draw a lot more power, but they draw almost nothing when executing scalar integer code.
CISC often has the ultimate advantage simply because it makes better use of the code cache.
If you're comparing to something like the Berkeley RISC or Alpha architecture, yes. If you're comparing to ARM... not so much. In the comparisons I've done, on both compiler-generate code and hand-written assembly, ARM and x86 are within 10% of each other in terms of code size with ARM smaller in most cases. Note that this was comparing ARM to x86 and x86-64. For a modern ARM core, you would use the Thumb-2 instruction set, which is typically about 30% smaller, and 50% smaller in the best case.
Reports of lack of strategy and poor management come out of Nokia
New CEO is hired, supposed to turn the company around
New CEO makes decisions that seem stupid to everyone else
Now, which do you think are more likely, that 4 propped up the share price dip that should have come from 1-3, in the hope that he'd actually do as promised and provide a sensible strategy, or that the dip was caused by the decision itself. Before you answer, note that the share price drop after the February announcement returned Nokia's shares to the same value that they had held in August 2010, just before Elop took over, which was 30% lower than it had been a few months earlier and a quarter of what it was in 2008...
The MS deal didn't really have anything to do with it. Nokia lost its way almost a decade ago. They flailed around trying a large number of incompatible things, with no overall direction. The Symbian kernel rewrite was probably the last good thing they did and they failed to couple it with a decent userland, so Symbian programmers were still stuck with APIs that were designed for systems with under 4MB of RAM. They made a few half-hearted attempts at moving to Linux (ignoring the fact that they already had a decent kernel, it was their userland that was the problem), and then seemed to completely lose the plot.
The MS deal was just another failure to fix the situation, in a long line of similar failures. It wasn't the cause, just another failed attempt at recovery.
I agree with the grandparent. IE2 was preinstalled. Upgrading to IE4 was possible via Windows update (but not the default) and since it was such a large download I didn't do that - it would have taken about an hour over my modem. On the other hand, both IE4 and Netscape 4 came on magazine cover disks. I had both installed, but ended up using IE4 because NS4 was crap. Opera might have been better, but I didn't try it until a few years later. Most of the people I knew at the time had similar experiences: they tried both and found IE4 superior.
That doesn't mean that Microsoft didn't abuse their monopoly to get it installed, but that doesn't alter the fact that it really was better than the competition back then...
There's also an LLVM linker under development (lld), which we (FreeBSD) will probably be importing to replace GNU ld once it's working. We have a wiki page tracking all of the GPL'd stuff in the base system and our plans on how to remove it before FreeBSD 10.
Two clauses. One was the broad patent license, which may result in accidentally licensing some patents that you didn't think you were licensing. The other is the termination clause, where if you are found to be in violation your license terminates with no mechanism for reinstating it once you return to compliance. The latter clause is the one that makes most companies nervous, as a simple error in distribution could result in their being unable to keep shipping their product.
Apple has a bunch of BSD code they've modified and never given out.
You claimed that twice, but didn't cite any examples. I can grab the sources for all of the FreeBSD-derived parts of libc and the kernel, for example, as well as all of use userspace utilities, from opensource.apple.com. There's little point in doing so, however, because Apple employs enough FreeBSD developers that most stuff that's sufficiently interesting gets pushed back by them already.
What I'm trying to say is that the BSD license does not encourage the collegiality which I believe is the GPL's greatest strength.
The 75+ companies represented at the Vendor Summit at BSDCan would disagree. The strong community was one of the most cited reasons for participating in FreeBSD development. The GPL doesn't force you to participate in the community, it just makes you do periodic code dumps. People who participate in a community because they feel that doing so is beneficial to them are a lot more valuable than people who grudgingly do so because a license forces them to.
Porting HAMMER is difficult because Dillon hacked up some bits of the VFS to make it work. These would need to be back-ported to FreeBSD for it to be possible. It also seems that HAMMER is basically dead from a development perspective now. I think it's quite likely that we'll port HAMMER2 at some point though, once it's stabilised.
A lot of FreeBSD code is shipping on every iOS, OS X, or Android device. Android's stack is mostly Apache and BSD licensed, with only a tiny bit of GPL. So, yes, just like that.
So e.g. bans on fully automatic firearms (and Predator drones and motorcycle mounted chainguns) are reasonable, while bans on widely used self-defense, hunting or sporting guns, such as your typical handgun or semi-auto rifle, are not.
Which is a strange interpretation, when you read the actual text of the amendment. It states that the justification for the right is the necessity of a well-maintained militia for the security of the state. With that in mind, sporting guns and those used for self defence are a lot less justifiable than predator drones, tanks, land mines, nuclear missiles, and other weapons that would actually be useful to a militia involved in defending the state...
Saying "no" is a lot cheaper because it involves the lawyer only.
Saying 'no' may also involve the lawyer for less time. If there's something obvious that should be refused, then it doesn't take as long to review the subpoena as if every single part needs to be approved. Saying no to all of them is probably even cheaper...
I'm not talking about physics at all. I get money by doing useful work for someone (or selling an asset, which was created by someone doing some useful work in the past). New money is introduced into the economy in a similar way, as loans that are contingent on future repayment (i.e. are the promise that the person getting the loan will do some work in the future that will allow them to repay the loan). Bitcoins are created by doing some useless computational work. The fact that it is harder to create them than a key pair affects their scarcity, not their value. It's hard to bottle pony farts, so they're quite scarce too, but basing a currency on them would be equally silly.
IBM did. I used one, and it was great. It was also $10,000. Oddly enough, there turns out not to be a big market for displays that cost $10K, and once both people in that market had bought them they stopped producing them.
Slashdot Mirror
Hi, what's it like in 2005? Over here in 2011, we have Thumb-2 as the standard instruction set for newly compiled ARM code (the Cortex-M series only supports it, The Cortex-A series supports ARM for legacy compatibility). Unlike Thumb-1, Thumb-2 can encode the entire ARM instruction set, with most instructions being 16 bits and some being 32. If you're using the unified assembly syntax, you can switch between the two with an assembler flag: the assembly code is the same because they're just two encodings of the same instruction set.
There's very little difference between the two instruction sets that makes one more power efficient than the other
There are two aspects of an instruction set that effect power consumption. One is density: how much instruction cache do you need for a given algorithm. ARM does about as well as i386 here, and Thumb-2 does better (typically about 20% smaller code than x86). Smaller instruction cache means less power consumption. The other is decoder complexity: how many transistors do you need to decode the instructions. x86 instructions are somewhere between 1 and 15 bytes, and the encoding scheme is highly non-othrogonal, so the logic required to decode them is very complex. ARM instructions are 32 bits and have fixed encoding and opcode fields, so you need a tiny handful of transistors to decode them. Thumb-2 instructions are variable length, but only come in two sizes (16 and 32 bits) and are only slightly more complex to decode. The micro-op decoder on a modern x86 chip is about as complex as the Thumb-2 decoder...
x86-64 can do register-memory type operands which is much more efficient
This thread is full of strange definitions. Requiring the CPU to do alias analysis, in hardware, at run time, is certainly not what I would call 'efficient', but sure, let's go with that definition for now...
Early ARM chips didn't have an integer divide instruction because it took up to 12 cycles[1] to perform integer division and you could get the same performance without complicating the pipeline without it. Integer division is often cited as one of the main reasons why RISC had problems, because newer techniques reduced the number of cycles required to perform integer division, so newer CISC chips just used those in place of the old microcoded loops, while RISC code got no benefit unless the instruction set was extended and the code recompiled. Modern RISC chips - including ARM - do have integer division instructions though, and compilers use them, so this is something of a moot point.
[1] It was a variable number, which made life very difficult for hardware designers. One of the benefits early RISC architectures had was the fact that their instructions took the same length of time to execute, so the pipeline could be very simple.
And yet Intel's first real entry into the phone processor market, Medfield, is equivalent to ARM in terms of power efficiency
This is a strange definition of 'equivalent' meaning 'uses more power at idle than a similarly performing ARM core does under full load'.
It's worth noting that with the Cortex A9 and newer, ARM has done a lot to standardise things. For example, interrupt controllers now have a standard well-defined interface. This means that once you have one Cortex A9 SoC working, getting the next working is about as hard as getting a new x86 laptop working: you may need device drivers for the GPU and a few other things, but the core functionality will be the same.
The instruction decoder is such an absurdly tiny part of a modern CPU that it really doesn't matter.
Not true. It is quite a small part, but it is the part that you can not turn off or put in a low power state as long as the CPU is doing anything. This is why it becomes important on low-power systems: it's a constant power drain. Big FPUs and SIMD units draw a lot more power, but they draw almost nothing when executing scalar integer code.
CISC often has the ultimate advantage simply because it makes better use of the code cache.
If you're comparing to something like the Berkeley RISC or Alpha architecture, yes. If you're comparing to ARM... not so much. In the comparisons I've done, on both compiler-generate code and hand-written assembly, ARM and x86 are within 10% of each other in terms of code size with ARM smaller in most cases. Note that this was comparing ARM to x86 and x86-64. For a modern ARM core, you would use the Thumb-2 instruction set, which is typically about 30% smaller, and 50% smaller in the best case.
Wouldn't it be a shame if the browsing histories of all of the current MPs happened to be leaked somewhere...
No one uses Triremes anymore.
Now, which do you think are more likely, that 4 propped up the share price dip that should have come from 1-3, in the hope that he'd actually do as promised and provide a sensible strategy, or that the dip was caused by the decision itself. Before you answer, note that the share price drop after the February announcement returned Nokia's shares to the same value that they had held in August 2010, just before Elop took over, which was 30% lower than it had been a few months earlier and a quarter of what it was in 2008...
So? That could equally mean that the shareholders took it as an indication that the new management had no idea how to correct the downwards spiral.
The Cambridge Diploma in Computer Science, which ran from 1953 to 2008, was the world's first taught course in computing
-Source
The MS deal didn't really have anything to do with it. Nokia lost its way almost a decade ago. They flailed around trying a large number of incompatible things, with no overall direction. The Symbian kernel rewrite was probably the last good thing they did and they failed to couple it with a decent userland, so Symbian programmers were still stuck with APIs that were designed for systems with under 4MB of RAM. They made a few half-hearted attempts at moving to Linux (ignoring the fact that they already had a decent kernel, it was their userland that was the problem), and then seemed to completely lose the plot.
The MS deal was just another failure to fix the situation, in a long line of similar failures. It wasn't the cause, just another failed attempt at recovery.
I agree with the grandparent. IE2 was preinstalled. Upgrading to IE4 was possible via Windows update (but not the default) and since it was such a large download I didn't do that - it would have taken about an hour over my modem. On the other hand, both IE4 and Netscape 4 came on magazine cover disks. I had both installed, but ended up using IE4 because NS4 was crap. Opera might have been better, but I didn't try it until a few years later. Most of the people I knew at the time had similar experiences: they tried both and found IE4 superior.
That doesn't mean that Microsoft didn't abuse their monopoly to get it installed, but that doesn't alter the fact that it really was better than the competition back then...
There's also an LLVM linker under development (lld), which we (FreeBSD) will probably be importing to replace GNU ld once it's working. We have a wiki page tracking all of the GPL'd stuff in the base system and our plans on how to remove it before FreeBSD 10.
Two clauses. One was the broad patent license, which may result in accidentally licensing some patents that you didn't think you were licensing. The other is the termination clause, where if you are found to be in violation your license terminates with no mechanism for reinstating it once you return to compliance. The latter clause is the one that makes most companies nervous, as a simple error in distribution could result in their being unable to keep shipping their product.
Apple has a bunch of BSD code they've modified and never given out.
You claimed that twice, but didn't cite any examples. I can grab the sources for all of the FreeBSD-derived parts of libc and the kernel, for example, as well as all of use userspace utilities, from opensource.apple.com. There's little point in doing so, however, because Apple employs enough FreeBSD developers that most stuff that's sufficiently interesting gets pushed back by them already.
What I'm trying to say is that the BSD license does not encourage the collegiality which I believe is the GPL's greatest strength.
The 75+ companies represented at the Vendor Summit at BSDCan would disagree. The strong community was one of the most cited reasons for participating in FreeBSD development. The GPL doesn't force you to participate in the community, it just makes you do periodic code dumps. People who participate in a community because they feel that doing so is beneficial to them are a lot more valuable than people who grudgingly do so because a license forces them to.
Porting HAMMER is difficult because Dillon hacked up some bits of the VFS to make it work. These would need to be back-ported to FreeBSD for it to be possible. It also seems that HAMMER is basically dead from a development perspective now. I think it's quite likely that we'll port HAMMER2 at some point though, once it's stabilised.
A lot of FreeBSD code is shipping on every iOS, OS X, or Android device. Android's stack is mostly Apache and BSD licensed, with only a tiny bit of GPL. So, yes, just like that.
So e.g. bans on fully automatic firearms (and Predator drones and motorcycle mounted chainguns) are reasonable, while bans on widely used self-defense, hunting or sporting guns, such as your typical handgun or semi-auto rifle, are not.
Which is a strange interpretation, when you read the actual text of the amendment. It states that the justification for the right is the necessity of a well-maintained militia for the security of the state. With that in mind, sporting guns and those used for self defence are a lot less justifiable than predator drones, tanks, land mines, nuclear missiles, and other weapons that would actually be useful to a militia involved in defending the state...
Saying "no" is a lot cheaper because it involves the lawyer only.
Saying 'no' may also involve the lawyer for less time. If there's something obvious that should be refused, then it doesn't take as long to review the subpoena as if every single part needs to be approved. Saying no to all of them is probably even cheaper...
Ah, I see. Apparently my reading comprehension requires more coffee.
I'm still missing why you believe that 'wasting electricity and computer cycles' is the opposite of 'not doing any useful work'.
I'm not talking about physics at all. I get money by doing useful work for someone (or selling an asset, which was created by someone doing some useful work in the past). New money is introduced into the economy in a similar way, as loans that are contingent on future repayment (i.e. are the promise that the person getting the loan will do some work in the future that will allow them to repay the loan). Bitcoins are created by doing some useless computational work. The fact that it is harder to create them than a key pair affects their scarcity, not their value. It's hard to bottle pony farts, so they're quite scarce too, but basing a currency on them would be equally silly.
IBM did. I used one, and it was great. It was also $10,000. Oddly enough, there turns out not to be a big market for displays that cost $10K, and once both people in that market had bought them they stopped producing them.