SANTA CLARA, Calif.--ARM Holdings has announced that its next-gen ARMv8 architecture will include the firm’s first 64-bit instruction set, pushing ARM-based processors into new segments of the consumer and enterprise markets.
Speaking at ARM TechCon 2011 in Santa Clara, Calif., ARM Chief Technology Officer Mike Muller said the new v8 architecture would consist of two main execution states: AArch64 and AArch32, with the former introducing a new A64 for 64-bit processing instruction set, while the latter would continue to support ARM’s existing instruction set.
“ARM V8 fully supports 32 bit ARMv7a software,” said Muller, adding that the architecture had been designed to “maximize the benefits across both 32-bit and 64-bit application areas."
This, he said, “would bring the advantages of energy-efficient 64-bit computing to new applications such as high-end servers and computing, as well as offering backwards compatibility and migration for existing software through a consistent architecture."
“A 64 bit OS can easily and efficiently support existing 32 bit software,” he explained.
Taking a dig at rival Intel Corp., Muller said that though the world had been done very well by Moore’s Law, “there’s nowhere else to go.” Muller said while more cores was certainly a good trend, ARM believed the future would be found in having “lots of power efficient cores rather than some more power inefficient cores.” Muller maintained that overall, the problems came down to the system level, not the cores.
ARM partners like Nvidia Corp. have already announced plans to target the server space, but before the announcement of 64-bit ARM architecture, that vision didn’t translate into much of a competitive reality, as server buyers were not likely to invest in machines that couldn’t handle the software they were running.
Despite the significance of the announcement, however, Muller warned that building a new architecture was not “a quick thing” and would take a few years, but was important in terms of scaling for ARM’s future. “It takes time to build ecosystems and we’re fully aware of that,” he said.
Indeed, the first processors based on ARMv8 will only be announced sometime in 2012, with actual server prototypes running on the new architecture expected in 2014.
“ARM was going to need to go 64-bit in the next 4-5 years for cell phones and tablets anyway,” explained analyst David Kanter of Real World Technologies. “The interesting part is that ARM partners such as Calxeda and Nvidia are clearly planning to target the server space, heading for a direction collision course with AMD, IBM, Intel and Oracle,” he said.
The question, said Kanter, was not whether ARM's 64-bit extensions would be perfectly functional, but whether ARM partners could deliver competitive products with the performance, power efficiency and reliability that customers require.
“Obviously Nvidia's strategy is going to be targeting HPC with GPUs, but that has never proven to be a market which can economically sustain a chip design company, much to SGI's detriment,” Kanter noted.
Another disadvantage, Kanter pointed out, was that most of ARM's partners were fabless and had less expertise when it came to custom design, unlike incumbents AMD, IBM, Intel and Oracle.
“They also have much less experience with the overall system and platform aspects, including the validation and testing required,” he said, explaining that for a product like a GPU –with a lifespan of about a year-- there wasn’t typically as much emphasis on correctness because bugs could be worked around. “In a server, there is very little tolerance for such things,” he said.
In his keynote address, Muller also spoke about the increased need for more heterogeneous computing, system partitioning, and solving the problems of energy efficiency in devices as systems became increasingly complex and memory intensive.
“Today, everything is an energy constrained system,” he said adding, “the solutions are all about building heterogeneous solutions.”
No Program counter just means the next location to execute does not default to P+1. The current micro-location is known and can be pushed on a stack with a "subroutine return" address bit flipped to create a return address when the subroutine returns. Many Prime Computers used the same tactic in their firmware next address units. Requires good software to allocate the firmware efficiently. Can't have two subroutine calls in a row without additional creativity unless you want to ping-pong forever.
You know, a decade or so back there was a phenomena of naming every one-researcher lab a "Center of Excellence" in this, that or the other thing. As though anyone ever started a "Center of Good Enough" or "Center of Mediocrity". This trend seems to have diminished. Thank heavens: many of these Centers weren't much more than a letterhead.
Precisely... if you are going to take up real estate with wide busses, then you may as well get everything you can for it. And that's more than addressing, branching, vector fields, and so on. There's only time, and space... if we are pushing the timing limits at the moment, then we can push out the space envelope as well.
128 bits isn't all about memmory addressing. Many fields like Cryptography and GPS can certainly benefit from wider registers, particularly a true 128 bit, quad precision floating point capability. But simple, everyday operations can also benefit as well. High clock rates and multiple cores aren't the only roads to performance increases. Just think about string matching 16 bytes at a time!
In addition to SIMD and vector operations, a wider instruction word allows you to build-in hardware n-way branches, where n might be 4 to 256. The wider word, ultimately, allows you to trade off space for time.
Why do you want 128-bit address widths?
32 bits only gives you 4Gbytes which is too small for servers.
64-bits gives you 1.8x10^19 bytes. That's more than 2Gbytes for every person on the planet and is probably more than is needed to address all the RAM in existence.
It is going to be a long time before we need a bigger address bus and it certainly is not worth the overhead for the foreseeable future.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.