You can currently find it in an ARM repository, accessible to ARM partners. It should be hitting the LLVM repository as soon as it's been cleared by the lawyers.
suddenly every store I go into has a "long-standing policy" that I never seemed to notice before that allows them to demand that I leave my $150 backpack with them (with no insurance against theft, etc.) if I want the privilege of buying their stuff
I've only seen this behaviour in one shop, and it was in the USA. My reaction was to politely tell them that if they are going to behave in an offensive manner (i.e. accusing me of shoplifting as soon as I walk in the door) then I have no intention of doing business with them and leave. If you go into such a shop and buy things, then you're just encouraging this kind of behaviour.
It was just abondoned because there was to little market for it,
No, it was abandoned because HP/Compaq ended up owning the Alpha and PA-RISC and Intel convinced them that they could lower costs by outsourcing their CPU design and use Itanium instead. There were still a lot of people who wanted to buy new Alphas, and they got stuck with Itaniums instead. The ones that weren't on VMS or NonStop just gave up and switched to commodity x86 and some open source *NIX.
That depends. If you market it as an ARM core without passing their compatibility test suite, then they'd be very unhappy. Similarly, if you violated any of their patents. But read the rest of my post: the point is that the number of potential customers is small. We actually have an ARMv7 implementation that runs in an FPGA that ARM knows about. They're quite happy with it, because it gives our students experience working with their architecture. There's a fairly widely distributed design from Edinburgh that is very ARM-like, but omits some of the harder bits, and again ARM is fine with it because it uses a different name.
But there's no reason why you could have multiple processes taking up more than 4GB in total - the kernel would just map their address space when they were running and unmap it when they weren't.
Actually, it's simpler than this with LPAE. ARM has a tagged TLB, and the way LPAE is implemented you don't even need to do the unmapping. LPAE just extends the page table format, so the translation is from a 32-bit input to a 40-bit output instead of from a 32-bit input to a 32-bit output.
What would "IP" mean anyway, with the fact that it is utterly impossible to ever control every single human being and computer you sent a copy to
We're talking about CPU designs. If you copy it illegally, then you have to spend a billion or so dollars on a fab. Or spend a few million to buy some time on someone else's (and hope that they don't check with ARM that you're actually a licensee). Enforcing copyright is pretty much impossible on mass-market goods, but when you're talking about something that has a target market of maybe 100 companies (if you're wildly optimistic) then it's not exactly hard to keep track of them.
And buying the ARM license doesn't just get you their core design. It also gets you access to their simulator and their (immense) verification suite, so that you can check if any of the modifications that you made broke compatibility with anything. And, most importantly, it gets you time with ARM engineers. If someone from Qualcomm or TI has a question about any aspect of the ARM architecture, they can get the engineer who designed that part on the phone almost immediately and they can probably get him put on a plane and sent over to them for a week quite quickly if they want more time. ARM doesn't just license their designs, they also license their expertise. ARM engineers spent a lot of time working with nVidia on their upcoming ARMv8 core, for example.
The mass scales with the volume, the power available from solar scales with the surface area, so the smaller you make it the more feasible solar is. That said, a number of aircraft manufacturers are working on solar powered aircraft, they're just doing it the sensible way: by refining biodiesel to something close to avgas and then modifying the engines to cope with the differences. There's a lot of space to collect the solar power on the ground, you don't need to do it in the air...
First, don't conflate the ABI and the ISA. The ABI, the Application Binary Interface, describes things like calling conventions, the sizes of fundamental types, the layout of C++ classes, vtables, RTTI, and so on. It is usually defined on a per-platform (OS-architecture pair) basis. This changes quite infrequently because changing it would break all existing binaries.
The ISA, Instruction Set Architecture, defines the set of operations that a CPU can execute and their encodings. These change quite frequently, but usually in a backwards-compatible way. For example, the latest AMD or Intel chips can still run early versions of MS DOS (although the BIOS and other hardware may be incompatible). ARM maintains backwards compatibility for userspace (unprivileged mode) code. You could run applications written for the ARM2 on a modern Cortex A15 if you had any. ARM does not, however, maintain compatibility for privileged mode operations between architectures. This means that kernels needed porting from ARMv5 to ARMv6, a little bit of porting from ARMv6 to ARMv7 and a fair bit more from ARMv7 to ARMv8. This means that they can fundamentally change the low-level parts of the system (for example, how it does virtual memory) but without breaking application compatibility. You may need a new kernel for the new CPU, but all of the rest of your code will keep working.
Backwards compatible changes happen very frequently. For example, Intel adds new SSE instructions with every CPU generation, ARM added NEON and so on. This is because each new generation adds more transistors, and you may as well use them for something. Once you've identified a set of operations that are commonly used, it's generally a good use of spare silicon to add hardware for them. This is increasingly common now because of the dark silicon problem: as transistor densities increase, you have a smaller proportion of the die area that can actually be used at a time if you want to keep within your heat dissipation limits. This means that it's increasingly sensible to add more obscure hardware (e.g. ARMv8 adds AES instructions) because it's a big power saving when it is used and it's not costing anything when it isn't (you couldn't use the transistors for anything that needs to be constantly powered, or your CPU would catch fire).
The A15 supports LPAE, so you can have a 40-bit physical address space with a 32-bit virtual address space. This lets you have up to 1TB of physical RAM in your tablet (which might be interesting if you wanted to memory map the flash directly), as long as no single application uses more than 4GB of address space. Given that on my 64-bit laptop, the process with the most virtual address space at the moment is using 1.2GB, I think that's probably a safe assumption for a few years...
It helps if you read what I wrote, rather than pasting random bits out of context. ARM Cortex-A50 chips are likely to appear in 2014 (maybe earlier, but probably not much earlier). ARM partners such as TSMC, nVidia, and Qualcomm, who have been developing their own ARMv8 implementations for the last 3 or so years are due to release production silicon in the first half of next years - they're shipping samples to their partners now.
Itanium was just a recompile. The problem was that the resulting code was then typically very slow, because Itanium is a complete bitch as a compiler target. In contrast, ARMv8 is a beautiful architecture to target. To give you some idea of how easy it is, the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation). LLVM, GCC and ICC all still suck at producing good code for Itanium, and they have had hundreds of man years of effort thrown at them.
All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more
The advantage of conditional instructions is that you can eliminate branches. The conditional instructions are always executed, but they're only retired if the predicates held. ARMv8 still has predicated select instructions, so you can implement exactly the same functionality, just do an unconditional instruction and then select the result based on the condition. The only case when this doesn't work is for loads and stores, and having predicated loads and stores massively complicates pipeline stage interactions anyway, so isn't such a clear win (you get better code density and fewer branches, but at the cost of a much more complex pipeline).
They also have the same set of conditional branches as ARMv7, but because the PC is not a GPR branch prediction becomes a lot easier. With ARMv7, any instruction can potentially be a branch and you need to know that the destination operand is the pc before you know whether it's a branch. This is great for software. You can do indirect branches with a load instruction, for example. Load with the pc as the target is insanely powerful and fun when writing ARM assembly, but it's a massive pain for branch prediction. This didn't matter on ARM6, because there was no branch predictor (and the pipeline was sufficiently short that it didn't matter), but it's a big problem on a Cortex A8 or newer. Now, the branch predictor only needs to get involved if the instruction has one of a small set of opcodes. This simplifies the interface between the decode unit and the branch predictor a lot. For example, it's easy to differentiate branches with a fixed offset from ones with a register target (which may go through completely different branch prediction mechanisms), just by the opcode. With ARMv7, an add with the pc as the destination takes two operands, a register and a flexible second operand, which may be a register, a register with the value shifted, or an immediate. If both registers are zero, then this is a fixed-destination branch. If one register is the pc, then it's a relative branch. Because pretty much any ARMv7 instruction can be a branch, the branch predictor interface to the decoder has two big disadvantages: it's very complex (not good for power) and it often doesn't get some of the information that it needs until a cycle later than one working just on branch and jump encodings would.
Load and store multiple are gone as well, but they're replaced with load and store pair. These give slightly lower instruction density, but they have the advantage that they complete in a more predictable amount of time, once again simplifying the pipeline, which reduces power consumption and increases the upper bound on clock frequency (which is related to the complexity of each pipeline stage).
They've also done quite a neat trick with the stack pointer. Register 0 is, like most RISC architectures, always 0, but when used as the base address for a load or store, this becomes the stack pointer with ARMv8, so they effectively get stack-relative addressing without having to introduce any extra opcodes (e.g. push and pop on x86) or make the stack a GPR.
ARMv8 also adds a very rich set of memory barriers, which map very cleanly to the C[++]11 memory ordering model. This is a big win when it comes to reducing bus traffic for cache coherency. This is a big win for power efficiency for multithreaded code, because it means that it's easy to do the exact minimum of synchronisation that the algorithm requires.
As an assembly programmer, I much prefer ARMv7, but as a compiler writer ARMv8 is a clear win. I spend a lot more time writing compilers than I spend writing assembly (and most people spend a lot more time using compilers than writing assembly). All of the things that they've removed are things that are hard to generate from a compiler (and hard to implement efficiently in silicon) and all of the things that they've added are useful for compilers. It's the first architecture I've seen where it looks like the architecture people actually talked to the compiler people before designing it.
The first drafts of the ARMv8 architecture became available to a few ARM partners about 4-5 years ago. They've since been working closely with these partners to produce their chips before releasing their own design. The aim was to have third-party silicon ready to ship before anyone started shipping ARM-designed parts to encourage more competition.
ARM intentionally delayed releasing their own designs to give the first-mover advantage to the partners that design their own cores. In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year. This is part of ARM's plan to be more directly competitive with the likes of Intel. Intel is a couple of magnitudes bigger than ARM, and can afford to have half a dozen teams designing chips for different market segments, including some that never make it to production because that market segment didn't exist by the time the chip was ready. ARM basically has one design, plus a seriously cut-down variant. By encouraging other implementations, they get to have chips designed for everything from ultra-low-power embedded systems (e.g. the Cortex-M0, which ARM licenses for about one cent per chip), through smartphone and tablet processors up to server chips. ARM will produce designs for some of these, and their design is quite modular, so it's relatively easy for SoC makers with the slightly more expensive licenses to tweak it a bit more to fit their use case, and companies like nVidia, TSMC and AMD will fill in the gaps.
The fact that ARM is now releasing their own designs for licensing means that their partners are very close to releasing shipping silicon. We've seen a few pre-production chips from a couple of vendors, but it's nice to see that they're about to hit the market.
[1] ARM engineers consulted on the designs, so there may be some common elements.
Not really. GPUs and CPUs are both general purpose processors, just optimised for different classes of algorithm. If you have an algorithm that makes sense on a GPU, then it's pretty easy to write OpenCL C to implement it. It's often much easier to implement efficiently than the CPU version. Getting the most possible performance out of a GPU is not so easy, but the same is true for a CPU.
Nyet. What I'm objecting to is the GGP up there saying that government-run wealth redistribution isn't done at the point of a gun. It's just fairy-tale nonsense.
It's only fairy-tale nonsense if you fail to realise that wealth-maintenance is also done at the point of a gun. It is only possible to be wealthy because society enforces your property rights at the point of a gun. If you want to be reductionist, every social interaction is at the point of a gun because if you stray too far from accepted behaviour then either society collectively or an individual will shoot you. That's a pointless and irrelevant argument and it's just as pointless in this situation.
Also, there is nothing about ARM that inherently makes it more powersaving @ the same performance level than other RISC CPUs, be it SPARC, POWER, MIPS and so on.
I can think of several things. For Thumb-2, there is instruction density. MIPS16 does about as well as Thumb-1, but it is massive pain to work with. AArch64 doesn't (yet) have a Thumb-3 encoding, but one will almost certainly appear after ARM has done a lot of profiling of the kinds of instruction that CPUs like to generate. Even in ARM mode, the big win over the other RISC architectures is the it has fairly complex addressing modes, so you can do things like structure and array offset calculations in one instruction on ARM or 3-4 on MIPS. For AArch32, you also have predicated instructions. These make a big difference on a very low power chip, because you don't need to have any branches for small conditionals. For AArch64, most of these are gone, but there is still a predicated move, which is a very powerful version of a select instruction and lets you do mostly the same things. With AArch32 you have store and load multiple instructions, which basically let you do all of your register spills and reloads in a single instruction (the instruction takes a mask of the registers to save, the register to use as the base, and whether to post- or pre- increment or decrement it as two flags). With AArch64, they replaced this with a store-pair instruction, which can store two registers, and has the advantage of being simpler to implement (fixed number of cycles to execute).
I am trying to grasp, somewhat desperately, the events that must have taken place inside AMD headquarters when the CPU design team said they wanted to do hyper-threading. Having seen how badly Intel got knocked around when they did it, and the fact that for the price of duplicating a fair amount of the CPU, you are still only occasionally eking out a slight performance gain...and sometimes, a performance loss, their strategy doesn't make sense
Perhaps they looked at IBM or Sun's implementation of SMT instead. Adding a second context to the POWER series added about 10% to the die area and gave around a 50% speedup. If you have multithreaded workloads (especially on a server) then it can significantly improve throughput for two very simple reasons. The first is that when one context has a cache miss, the CPU doesn't sit idle, it can let the other core work. The second is that it makes branch misprediction penalties lower, because if you're issuing instructions alternately from two contexts you can get the instruction that the branch depends on a lot closer to the end of the pipeline than before you need to make the prediction. This also helps with various other hazards, so you don't need so much logic for out-of-order execution to get the same throughput.
It's a relatively small club. Note that both the headline and summary are wrong. AMD has not licensed a processor design, they have licensed the right to make their own implementation of the ARMv8 architecture (which isn't just a piece of paper, it includes access to ARM's rich set of regression tests and assistance from ARM engineers when requested on both the hardware design and the supporting software). I know of three other companies working on ARMv8 designs. For ARMv7, I think there is basically only ARM with the Cortex series and Qualcomm with the Snapdragon (which is a massively hacked-up Cortex A8, with a completely redesigned FPU, a better interconnect, and some other improvements, but not a complete independent implementation). Compare this with the ARMv4 and ARMv5 situation, where StrongARM and XScale were complete independent implementations. ARM has intentionally delayed producing their own ARMv8 design to give other companies a chance and promote more competition. This worked very well for x86 during the '90s, when Intel, AMD, Cyrix/IBM, IDT, and others were all pushing out compatible products at different market segments. In the ARM world, because they all have to go through the same set of conformance tests, compatibility should be even higher.
My guess would be that, although the fabs are different, the underlying processes are similar and that's where a huge amount of Intel R&D money goes. Intel's big advantage over the last couple of decades has been outspending everyone else on process technology, so they're always at least half a generation ahead. If they can use this investment in another product line, then that reduces the amount of the price of every CPU that has to go towards R&D.
The other part of the problem, I would suspect, comes from some simulator results that Intel published about a decade ago. When they make a new CPU, they first run it in a complete simulation environment, where every aspect can be adjusted. They tried making the CPU infinitely fast in one experiment (i.e. every CPU cycle takes 0 simulation time) and found that this increased the overall performance by a factor of two. All it did was move the bottlenecks to memory and disks. Ensuring that fast disks are available helps stimulate the market for faster CPUs. We've seen recently in the FreeBSD kernel that the mantra for the last 20 years in a lot of places in the storage stack has been 'don't worry about optimising that - it's on a code path that does I/O, so the extra CPU time will be lost in the noise'. Then you replace a 150IO/s, 50MB/s spinning disk with a 10,000IO/s, 300MB/s SSD and suddenly it becomes a lot less true: operations you used to be able to hide in the 5-10ms of seek time are now quite noticeable and can cause real slowdowns when that seek time becomes a single microsecond.
I'd be perfectly happy for people not to pay taxes, as long as they were then happy to go without any of the protections afforded by being members of society. This includes, for example, recourse to the legal system is someone takes their property or harms their person. The problem with your argument is that you appear to believe that it's fine for society to enforce property rights, but that requiring active participation in society in exchange for this is a bad thing.
Profit is not evil. There are a number of triple bottom line companies now, with the three goals of people, planet, and profit. The first means don't exploit your employees or customers, but make fair exchanges with both so that both parties come out better off than they started. The second means don't exploit externalities and account for all of the costs of doing business, even those that you would not be required by law to carry. And the last is obvious and note that it is present and still important: it's entirely possible to be profitable without being evil and doing so is important for your endeavour's sustainability.
Would you rather the people just sit at home unemployed? I'd rather the government pay people to build, then knock over buildings, than have them unemployed, hungry and ready to rob me to feed their kids.
There is an unspoken assumption and a false dichotomies in there. The first is the assumption that if they're not working then they will be less happy and more likely to rob you. I bet a lot of construction workers (and, indeed, people in general) would be just as happy to be paid to do nothing as being paid to do busy work. The second is that the choice is pay them to do something silly or don't have them do anything, when in reality they could also be paid to do something of actual benefit to society, such as build railways or some other infrastructure that a large proportion of the population will use.
Given that Intel is trying to wind down its StrongARM line it inherited from DEC, AMD may see the ARM line as a place where it can finally be top dog
Intel isn't trying to wind this line down, they sold it outright to Marvell two years ago. Even then, they were pretty anaemic. XScale was the P4 of the ARM world: twice as high a clock speed as everyone else but a much lower instruction-per-clock. It's an ARMv5 implementation, which seems painfully archaic today (especially given the lack of FPU, which even most ARMv6 implementations have).
Is typing someone's name into a search engine 'digging shit up' about them? Anything a search engine can find about me is likely to be stuff that I've intentionally made public, and so it's stuff I'm happy to have friends do it and potentially discover mutual interests that just haven't come up in conversation. It's not like paying a PI to follow someone around...
Slashdot Mirror
You can currently find it in an ARM repository, accessible to ARM partners. It should be hitting the LLVM repository as soon as it's been cleared by the lawyers.
And the more important question: will he be changing his name to Kim Dotga?
suddenly every store I go into has a "long-standing policy" that I never seemed to notice before that allows them to demand that I leave my $150 backpack with them (with no insurance against theft, etc.) if I want the privilege of buying their stuff
I've only seen this behaviour in one shop, and it was in the USA. My reaction was to politely tell them that if they are going to behave in an offensive manner (i.e. accusing me of shoplifting as soon as I walk in the door) then I have no intention of doing business with them and leave. If you go into such a shop and buy things, then you're just encouraging this kind of behaviour.
It was just abondoned because there was to little market for it,
No, it was abandoned because HP/Compaq ended up owning the Alpha and PA-RISC and Intel convinced them that they could lower costs by outsourcing their CPU design and use Itanium instead. There were still a lot of people who wanted to buy new Alphas, and they got stuck with Itaniums instead. The ones that weren't on VMS or NonStop just gave up and switched to commodity x86 and some open source *NIX.
That depends. If you market it as an ARM core without passing their compatibility test suite, then they'd be very unhappy. Similarly, if you violated any of their patents. But read the rest of my post: the point is that the number of potential customers is small. We actually have an ARMv7 implementation that runs in an FPGA that ARM knows about. They're quite happy with it, because it gives our students experience working with their architecture. There's a fairly widely distributed design from Edinburgh that is very ARM-like, but omits some of the harder bits, and again ARM is fine with it because it uses a different name.
But there's no reason why you could have multiple processes taking up more than 4GB in total - the kernel would just map their address space when they were running and unmap it when they weren't.
Actually, it's simpler than this with LPAE. ARM has a tagged TLB, and the way LPAE is implemented you don't even need to do the unmapping. LPAE just extends the page table format, so the translation is from a 32-bit input to a 40-bit output instead of from a 32-bit input to a 32-bit output.
What would "IP" mean anyway, with the fact that it is utterly impossible to ever control every single human being and computer you sent a copy to
We're talking about CPU designs. If you copy it illegally, then you have to spend a billion or so dollars on a fab. Or spend a few million to buy some time on someone else's (and hope that they don't check with ARM that you're actually a licensee). Enforcing copyright is pretty much impossible on mass-market goods, but when you're talking about something that has a target market of maybe 100 companies (if you're wildly optimistic) then it's not exactly hard to keep track of them.
And buying the ARM license doesn't just get you their core design. It also gets you access to their simulator and their (immense) verification suite, so that you can check if any of the modifications that you made broke compatibility with anything. And, most importantly, it gets you time with ARM engineers. If someone from Qualcomm or TI has a question about any aspect of the ARM architecture, they can get the engineer who designed that part on the phone almost immediately and they can probably get him put on a plane and sent over to them for a week quite quickly if they want more time. ARM doesn't just license their designs, they also license their expertise. ARM engineers spent a lot of time working with nVidia on their upcoming ARMv8 core, for example.
The mass scales with the volume, the power available from solar scales with the surface area, so the smaller you make it the more feasible solar is. That said, a number of aircraft manufacturers are working on solar powered aircraft, they're just doing it the sensible way: by refining biodiesel to something close to avgas and then modifying the engines to cope with the differences. There's a lot of space to collect the solar power on the ground, you don't need to do it in the air...
First, don't conflate the ABI and the ISA. The ABI, the Application Binary Interface, describes things like calling conventions, the sizes of fundamental types, the layout of C++ classes, vtables, RTTI, and so on. It is usually defined on a per-platform (OS-architecture pair) basis. This changes quite infrequently because changing it would break all existing binaries.
The ISA, Instruction Set Architecture, defines the set of operations that a CPU can execute and their encodings. These change quite frequently, but usually in a backwards-compatible way. For example, the latest AMD or Intel chips can still run early versions of MS DOS (although the BIOS and other hardware may be incompatible). ARM maintains backwards compatibility for userspace (unprivileged mode) code. You could run applications written for the ARM2 on a modern Cortex A15 if you had any. ARM does not, however, maintain compatibility for privileged mode operations between architectures. This means that kernels needed porting from ARMv5 to ARMv6, a little bit of porting from ARMv6 to ARMv7 and a fair bit more from ARMv7 to ARMv8. This means that they can fundamentally change the low-level parts of the system (for example, how it does virtual memory) but without breaking application compatibility. You may need a new kernel for the new CPU, but all of the rest of your code will keep working.
Backwards compatible changes happen very frequently. For example, Intel adds new SSE instructions with every CPU generation, ARM added NEON and so on. This is because each new generation adds more transistors, and you may as well use them for something. Once you've identified a set of operations that are commonly used, it's generally a good use of spare silicon to add hardware for them. This is increasingly common now because of the dark silicon problem: as transistor densities increase, you have a smaller proportion of the die area that can actually be used at a time if you want to keep within your heat dissipation limits. This means that it's increasingly sensible to add more obscure hardware (e.g. ARMv8 adds AES instructions) because it's a big power saving when it is used and it's not costing anything when it isn't (you couldn't use the transistors for anything that needs to be constantly powered, or your CPU would catch fire).
The A15 supports LPAE, so you can have a 40-bit physical address space with a 32-bit virtual address space. This lets you have up to 1TB of physical RAM in your tablet (which might be interesting if you wanted to memory map the flash directly), as long as no single application uses more than 4GB of address space. Given that on my 64-bit laptop, the process with the most virtual address space at the moment is using 1.2GB, I think that's probably a safe assumption for a few years...
It helps if you read what I wrote, rather than pasting random bits out of context. ARM Cortex-A50 chips are likely to appear in 2014 (maybe earlier, but probably not much earlier). ARM partners such as TSMC, nVidia, and Qualcomm, who have been developing their own ARMv8 implementations for the last 3 or so years are due to release production silicon in the first half of next years - they're shipping samples to their partners now.
Itanium was just a recompile. The problem was that the resulting code was then typically very slow, because Itanium is a complete bitch as a compiler target. In contrast, ARMv8 is a beautiful architecture to target. To give you some idea of how easy it is, the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation). LLVM, GCC and ICC all still suck at producing good code for Itanium, and they have had hundreds of man years of effort thrown at them.
All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more
The advantage of conditional instructions is that you can eliminate branches. The conditional instructions are always executed, but they're only retired if the predicates held. ARMv8 still has predicated select instructions, so you can implement exactly the same functionality, just do an unconditional instruction and then select the result based on the condition. The only case when this doesn't work is for loads and stores, and having predicated loads and stores massively complicates pipeline stage interactions anyway, so isn't such a clear win (you get better code density and fewer branches, but at the cost of a much more complex pipeline).
They also have the same set of conditional branches as ARMv7, but because the PC is not a GPR branch prediction becomes a lot easier. With ARMv7, any instruction can potentially be a branch and you need to know that the destination operand is the pc before you know whether it's a branch. This is great for software. You can do indirect branches with a load instruction, for example. Load with the pc as the target is insanely powerful and fun when writing ARM assembly, but it's a massive pain for branch prediction. This didn't matter on ARM6, because there was no branch predictor (and the pipeline was sufficiently short that it didn't matter), but it's a big problem on a Cortex A8 or newer. Now, the branch predictor only needs to get involved if the instruction has one of a small set of opcodes. This simplifies the interface between the decode unit and the branch predictor a lot. For example, it's easy to differentiate branches with a fixed offset from ones with a register target (which may go through completely different branch prediction mechanisms), just by the opcode. With ARMv7, an add with the pc as the destination takes two operands, a register and a flexible second operand, which may be a register, a register with the value shifted, or an immediate. If both registers are zero, then this is a fixed-destination branch. If one register is the pc, then it's a relative branch. Because pretty much any ARMv7 instruction can be a branch, the branch predictor interface to the decoder has two big disadvantages: it's very complex (not good for power) and it often doesn't get some of the information that it needs until a cycle later than one working just on branch and jump encodings would.
Load and store multiple are gone as well, but they're replaced with load and store pair. These give slightly lower instruction density, but they have the advantage that they complete in a more predictable amount of time, once again simplifying the pipeline, which reduces power consumption and increases the upper bound on clock frequency (which is related to the complexity of each pipeline stage).
They've also done quite a neat trick with the stack pointer. Register 0 is, like most RISC architectures, always 0, but when used as the base address for a load or store, this becomes the stack pointer with ARMv8, so they effectively get stack-relative addressing without having to introduce any extra opcodes (e.g. push and pop on x86) or make the stack a GPR.
ARMv8 also adds a very rich set of memory barriers, which map very cleanly to the C[++]11 memory ordering model. This is a big win when it comes to reducing bus traffic for cache coherency. This is a big win for power efficiency for multithreaded code, because it means that it's easy to do the exact minimum of synchronisation that the algorithm requires.
As an assembly programmer, I much prefer ARMv7, but as a compiler writer ARMv8 is a clear win. I spend a lot more time writing compilers than I spend writing assembly (and most people spend a lot more time using compilers than writing assembly). All of the things that they've removed are things that are hard to generate from a compiler (and hard to implement efficiently in silicon) and all of the things that they've added are useful for compilers. It's the first architecture I've seen where it looks like the architecture people actually talked to the compiler people before designing it.
The first drafts of the ARMv8 architecture became available to a few ARM partners about 4-5 years ago. They've since been working closely with these partners to produce their chips before releasing their own design. The aim was to have third-party silicon ready to ship before anyone started shipping ARM-designed parts to encourage more competition.
ARM intentionally delayed releasing their own designs to give the first-mover advantage to the partners that design their own cores. In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year. This is part of ARM's plan to be more directly competitive with the likes of Intel. Intel is a couple of magnitudes bigger than ARM, and can afford to have half a dozen teams designing chips for different market segments, including some that never make it to production because that market segment didn't exist by the time the chip was ready. ARM basically has one design, plus a seriously cut-down variant. By encouraging other implementations, they get to have chips designed for everything from ultra-low-power embedded systems (e.g. the Cortex-M0, which ARM licenses for about one cent per chip), through smartphone and tablet processors up to server chips. ARM will produce designs for some of these, and their design is quite modular, so it's relatively easy for SoC makers with the slightly more expensive licenses to tweak it a bit more to fit their use case, and companies like nVidia, TSMC and AMD will fill in the gaps.
The fact that ARM is now releasing their own designs for licensing means that their partners are very close to releasing shipping silicon. We've seen a few pre-production chips from a couple of vendors, but it's nice to see that they're about to hit the market.
[1] ARM engineers consulted on the designs, so there may be some common elements.
Not really. GPUs and CPUs are both general purpose processors, just optimised for different classes of algorithm. If you have an algorithm that makes sense on a GPU, then it's pretty easy to write OpenCL C to implement it. It's often much easier to implement efficiently than the CPU version. Getting the most possible performance out of a GPU is not so easy, but the same is true for a CPU.
Nyet. What I'm objecting to is the GGP up there saying that government-run wealth redistribution isn't done at the point of a gun. It's just fairy-tale nonsense.
It's only fairy-tale nonsense if you fail to realise that wealth-maintenance is also done at the point of a gun. It is only possible to be wealthy because society enforces your property rights at the point of a gun. If you want to be reductionist, every social interaction is at the point of a gun because if you stray too far from accepted behaviour then either society collectively or an individual will shoot you. That's a pointless and irrelevant argument and it's just as pointless in this situation.
Also, there is nothing about ARM that inherently makes it more powersaving @ the same performance level than other RISC CPUs, be it SPARC, POWER, MIPS and so on.
I can think of several things. For Thumb-2, there is instruction density. MIPS16 does about as well as Thumb-1, but it is massive pain to work with. AArch64 doesn't (yet) have a Thumb-3 encoding, but one will almost certainly appear after ARM has done a lot of profiling of the kinds of instruction that CPUs like to generate. Even in ARM mode, the big win over the other RISC architectures is the it has fairly complex addressing modes, so you can do things like structure and array offset calculations in one instruction on ARM or 3-4 on MIPS. For AArch32, you also have predicated instructions. These make a big difference on a very low power chip, because you don't need to have any branches for small conditionals. For AArch64, most of these are gone, but there is still a predicated move, which is a very powerful version of a select instruction and lets you do mostly the same things. With AArch32 you have store and load multiple instructions, which basically let you do all of your register spills and reloads in a single instruction (the instruction takes a mask of the registers to save, the register to use as the base, and whether to post- or pre- increment or decrement it as two flags). With AArch64, they replaced this with a store-pair instruction, which can store two registers, and has the advantage of being simpler to implement (fixed number of cycles to execute).
I am trying to grasp, somewhat desperately, the events that must have taken place inside AMD headquarters when the CPU design team said they wanted to do hyper-threading. Having seen how badly Intel got knocked around when they did it, and the fact that for the price of duplicating a fair amount of the CPU, you are still only occasionally eking out a slight performance gain...and sometimes, a performance loss, their strategy doesn't make sense
Perhaps they looked at IBM or Sun's implementation of SMT instead. Adding a second context to the POWER series added about 10% to the die area and gave around a 50% speedup. If you have multithreaded workloads (especially on a server) then it can significantly improve throughput for two very simple reasons. The first is that when one context has a cache miss, the CPU doesn't sit idle, it can let the other core work. The second is that it makes branch misprediction penalties lower, because if you're issuing instructions alternately from two contexts you can get the instruction that the branch depends on a lot closer to the end of the pipeline than before you need to make the prediction. This also helps with various other hazards, so you don't need so much logic for out-of-order execution to get the same throughput.
It's a relatively small club. Note that both the headline and summary are wrong. AMD has not licensed a processor design, they have licensed the right to make their own implementation of the ARMv8 architecture (which isn't just a piece of paper, it includes access to ARM's rich set of regression tests and assistance from ARM engineers when requested on both the hardware design and the supporting software). I know of three other companies working on ARMv8 designs. For ARMv7, I think there is basically only ARM with the Cortex series and Qualcomm with the Snapdragon (which is a massively hacked-up Cortex A8, with a completely redesigned FPU, a better interconnect, and some other improvements, but not a complete independent implementation). Compare this with the ARMv4 and ARMv5 situation, where StrongARM and XScale were complete independent implementations. ARM has intentionally delayed producing their own ARMv8 design to give other companies a chance and promote more competition. This worked very well for x86 during the '90s, when Intel, AMD, Cyrix/IBM, IDT, and others were all pushing out compatible products at different market segments. In the ARM world, because they all have to go through the same set of conformance tests, compatibility should be even higher.
My guess would be that, although the fabs are different, the underlying processes are similar and that's where a huge amount of Intel R&D money goes. Intel's big advantage over the last couple of decades has been outspending everyone else on process technology, so they're always at least half a generation ahead. If they can use this investment in another product line, then that reduces the amount of the price of every CPU that has to go towards R&D.
The other part of the problem, I would suspect, comes from some simulator results that Intel published about a decade ago. When they make a new CPU, they first run it in a complete simulation environment, where every aspect can be adjusted. They tried making the CPU infinitely fast in one experiment (i.e. every CPU cycle takes 0 simulation time) and found that this increased the overall performance by a factor of two. All it did was move the bottlenecks to memory and disks. Ensuring that fast disks are available helps stimulate the market for faster CPUs. We've seen recently in the FreeBSD kernel that the mantra for the last 20 years in a lot of places in the storage stack has been 'don't worry about optimising that - it's on a code path that does I/O, so the extra CPU time will be lost in the noise'. Then you replace a 150IO/s, 50MB/s spinning disk with a 10,000IO/s, 300MB/s SSD and suddenly it becomes a lot less true: operations you used to be able to hide in the 5-10ms of seek time are now quite noticeable and can cause real slowdowns when that seek time becomes a single microsecond.
I'd be perfectly happy for people not to pay taxes, as long as they were then happy to go without any of the protections afforded by being members of society. This includes, for example, recourse to the legal system is someone takes their property or harms their person. The problem with your argument is that you appear to believe that it's fine for society to enforce property rights, but that requiring active participation in society in exchange for this is a bad thing.
Profit is not evil. There are a number of triple bottom line companies now, with the three goals of people, planet, and profit. The first means don't exploit your employees or customers, but make fair exchanges with both so that both parties come out better off than they started. The second means don't exploit externalities and account for all of the costs of doing business, even those that you would not be required by law to carry. And the last is obvious and note that it is present and still important: it's entirely possible to be profitable without being evil and doing so is important for your endeavour's sustainability.
Would you rather the people just sit at home unemployed? I'd rather the government pay people to build, then knock over buildings, than have them unemployed, hungry and ready to rob me to feed their kids.
There is an unspoken assumption and a false dichotomies in there. The first is the assumption that if they're not working then they will be less happy and more likely to rob you. I bet a lot of construction workers (and, indeed, people in general) would be just as happy to be paid to do nothing as being paid to do busy work. The second is that the choice is pay them to do something silly or don't have them do anything, when in reality they could also be paid to do something of actual benefit to society, such as build railways or some other infrastructure that a large proportion of the population will use.
Given that Intel is trying to wind down its StrongARM line it inherited from DEC, AMD may see the ARM line as a place where it can finally be top dog
Intel isn't trying to wind this line down, they sold it outright to Marvell two years ago. Even then, they were pretty anaemic. XScale was the P4 of the ARM world: twice as high a clock speed as everyone else but a much lower instruction-per-clock. It's an ARMv5 implementation, which seems painfully archaic today (especially given the lack of FPU, which even most ARMv6 implementations have).
Is typing someone's name into a search engine 'digging shit up' about them? Anything a search engine can find about me is likely to be stuff that I've intentionally made public, and so it's stuff I'm happy to have friends do it and potentially discover mutual interests that just haven't come up in conversation. It's not like paying a PI to follow someone around...