Apple stole a march on Android when it released the iPhone 5S with a 64-bit processor, and Android manufacturers have put the pedal to the metal in a race to catch up and make their products 64-bit. AnandTech reports that HTC has announced the Desire 510, its first 64-bit Android phone.
Meanwhile, AnandTech describe the device in more detail:
While normally one might expect high end phones to get the latest and greatest features first, this time we see a bit of a surprising reversal. The Desire 510 is HTC's first 64-bit phone, and the first announced device with Snapdragon 410. For those that aren't familiar with Snapdragon 410, it has four Cortex A53 CPU cores running at 1.2 GHz, along with an Adreno 306 GPU which suggests that it is a mild modification of the current Adreno 305 GPU that we see in the Snapdragon 400. Overall, this should make for a quite fast SoC compared to Snapdragon 400, as Anand has covered in the Snapdragon 410 launch announcement.
While it may seem strange that ARMv8 on Android phones is first to appear on a budget smartphone, it's quite easy to understand how this happened. Looking at Qualcomm's roadmap, the Snapdragon 810/MSM8994 is the first high-end SoC that will ship with ARMv8, and is built on a 20nm process. As 20nm from both Samsung and TSMC have just begun appearing in shipping chips, the process yield and production capacity isn't nearly as mature as 28nm LP, which is old news by now.
Other details include:
- SoC: MSM8916 1.2 GHz Snapdragon 410
- RAM/NAND: 1 GB RAM, 8GB NAND + microSD
- Display: 4.7” FWVGA (854x480)
- Network: 2G / 3G / 4G LTE (Qualcomm MDM9x25 UE Category 4 LTE)
- Dimensions: 139.9 x 69.8 x 9.99mm
- Weight: 158 grams
- Camera: 5MP rear camera, .3MP/VGA FFC
- Battery: 2100 mAh (7.98 Whr)
- OS: Android 4.4 with Sense 6
- Connectivity: 802.11b/g/n + BT 4.0, USB2.0, GPS/GNSS, DLNA
- SIM Size: MicroSIM
(Score: 4, Interesting) by jasassin on Saturday August 30 2014, @02:25PM
What is the purpose of a 64bit CPU in a cell phone with less than 4 gigs of ram?
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 1, Insightful) by Anonymous Coward on Saturday August 30 2014, @03:25PM
To force all your users to replace all their 32 bit apps when you stop supporting them.
(Score: 2) by Tork on Sunday August 31 2014, @12:03AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 1) by tonyPick on Saturday August 30 2014, @06:33PM
One possibility is: At least in part you can (eventually) ditch your 32 bit platforms, and reduce the number of SoC devices to support in your platform roadmap, so you end up using the same, or very similar, tools (compilers loaders, test harness, blah blah blah) throughout the product range for your next-gen platforms, which is a net win, even if you don't use the all the features in the simpler cases.
(Score: 3, Informative) by davester666 on Saturday August 30 2014, @07:08PM
it's not just about 64-bit address space, it also has a bunch more fp and gp registers, which means code doesn't have to dump stuff to memory as much, so for the same clock speed, 64 bit code actually runs faster.
(Score: 2) by Grishnakh on Saturday August 30 2014, @10:15PM
That's x86. The x86 architecture was not that well designed, and is register-starved. When AMD designed the x86-64 architecture, they took the opportunity to greatly increase the number of registers.
ARM CPUs don't have this limitation. ARMs have always had lots of registers.
(Score: 2) by davester666 on Sunday August 31 2014, @05:17AM
64-bit ARM has twice the number of GP and FP registers [32 each vs 16 each for 32-bit Cortex ARM cpus].
Apple claims that just recompiling for 64-bit ARM [at least for their chip] gives around a 30% speedup for cpu-dependent code vs the same 32-bit code on an iPhone 5S and other's have checked and confirmed it [of course it is approximate and depends on the specific code].
(Score: 2) by BasilBrush on Saturday August 30 2014, @07:19PM
Moving to 64-bit ARM gives a new architecture and extra registers which speed things up.
Plus it's ready for when phones do have more than 4GB memory.
Hurrah! Quoting works now!
(Score: 2) by c0lo on Saturday August 30 2014, @10:44PM
Public health. Via larger (thus heavier) battery needed and/or more frequent recharges (thus xtra effort to reach low placed power socket plugs [soylentnews.org]).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 5, Interesting) by Subsentient on Saturday August 30 2014, @04:12PM
Please don't bring smartphone and cloud BS onto Soylent News. I tolerate this garbage everywhere else, and I'd like to maintain the illusion that the world is still somewhat intelligent and sane, even though it doesn't work too well when I walk down the street trying not to see the zombie pedestrians on their smartphones.
A smartphone is not a computer, fiddling with and rooting the phone for ten hours to jam in an alternative OS does not mean the phone can boot any OS, and the Nexus is NOT the standard in Android phones, not every one can boot anything else. Smartphones with their $0.99 apps, as well as the cloud with its 'don't-expect-open-source' are a severe blow to open source in general and mark my words, if you people don't wake up, they'll kill off desktops except the highest workstations and turn all laptops into Chromebook clones with boot-locked firmware.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 3, Insightful) by Horse With Stripes on Saturday August 30 2014, @04:29PM
I'm pretty sure the market will decide what is and isn't available to consumers, enterprise customers, power users, platform zealots, DIY types, bleeding edge crash test dummies, etc, etc. Though I am a proponent of open source, not everything is going to be open source, and not every piece of closed source software is a blow to open source software (just like not every piece of open source software is a blow to proprietary products).
The market is changing and will continue to change. Of course the marketing people will try to drive the market, but actual purchasing is the real deciding factor (just look at the first few versions of Microsoft's Surface).
(Score: 3, Informative) by Subsentient on Sunday August 31 2014, @02:25AM
I don't live an an Ayn-Randian dreamworld, I live in the world where companies with their standard-issue poor ethics will happily fuck over the consumer to add restrictions that will increase their bottom line and gain them power and control. That's life. Most people don't give enough of a damn for this kind of thing to seriously influence people, they'll just believe whatever propaganda is spewed in popular culture and media.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by tibman on Saturday August 30 2014, @04:46PM
Don't worry too much about desktops. The games market will keep them alive and kicking : )
SN won't survive on lurkers alone. Write comments.
(Score: 3, Insightful) by kaszz on Saturday August 30 2014, @05:28PM
Actually less than good forces tries to remove the desktop from the market.
Make software that needs a proper desktop (or laptop) such that all zombiephones are put to an disadvantage.
(Score: 2) by BasilBrush on Saturday August 30 2014, @07:26PM
Phones certainly are most certainly computers. The won't "kill off desktops", but even if they did, that would be tech news that certainly needs coverage here.
And whether or not you can replace the OS is irrelevant. You seem to be under the mistaken impression that Soylent News is dedicated to open source topics. It's not.
Hurrah! Quoting works now!
(Score: 2) by Subsentient on Sunday August 31 2014, @05:41PM
It matters because by definition a computer must be capable of running ANY arbitrary code built for it. It matters because I revile Android with a passion. It matters because you multi-hundred-dollar iPad is incapable of running anything but iOS. It matters because freedom. Most people don't give a damn, but then again many people throw away their computer when Windows becomes corrupted.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by BasilBrush on Sunday August 31 2014, @08:51PM
It matters because by definition a computer must be capable of running ANY arbitrary code built for it.
What and who's definition is that? There is no such definition that specifies that ANYONE must be allowed to program it. At best you're confusing politics and technical definitions. More likely you're inventing definitions as you go.
Again, open source and open platforms do NOT define what's tech news, nor what's news here.
Hurrah! Quoting works now!
(Score: 0) by Anonymous Coward on Saturday August 30 2014, @11:13PM
Seriously, if the phone in question is not an iPhone it isn't even news. Nobody cares about these shitty android phones and neither should we. The iPhone is the only phone worth looking at.
(Score: 2) by SlimmPickens on Sunday August 31 2014, @02:38AM
Think of it as a potential server / mobile router.
Once Ubuntu Phone is launched (which uses android drivers and file layout, but is otherwise an ARM compiled Ubuntu) how long could it take for Debian phone to appear?
(Score: 4, Insightful) by Jaruzel on Saturday August 30 2014, @06:06PM
... that the OS, AND the Apps are all still 32 bit. The ONLY reason this phone has a 64 bit CPU in it at this time, is because Apple did it first in theirs.
There is no pressing reason to put a 64 bit CPU in a phone, but if you look at the metrics of scale, having all your CPUs that roll off the CPU factory on the same basic form factor makes way more sense - ARM CPUs aren't just put in phones.
-Jar
This is my opinion, there are many others, but this one is mine.
(Score: 1) by Username on Saturday August 30 2014, @07:01PM
Why not make a 96 bit or 128 bit registers?
(Score: 4, Interesting) by BasilBrush on Saturday August 30 2014, @07:42PM
For PCs, roughly speaking, the move from 4-bit to 8-bit took about 2 years.
8-bit to 16-bit: 4 years
16-bit to 32-bit: 8 years
32-bit to 64-bit: 16 years.
The move from 32-64 phones started last year, so one should expect a move to 128-bit phones round about the year 2045. By then we'll be starting to be able to come up with a justification for it.
Hurrah! Quoting works now!
(Score: 2) by HiThere on Saturday August 30 2014, @07:50PM
There actually have been designs for 128 bit cpus...but not that are based around the x86 opcodes. There are even decent arguments as to why they are desirable. IIRC, some of them have partitioned instruction sets that allow some selections of opcodes to be packed at more than one to a word, and others to handle indirect access to multiple RAM locations in the same instruction. (With modern RAM sizes, that might require more than 128 bits of instruction, but back in the day that this was being proposed, it could have worked well...possibly did work well.
The thing about modern 64bit processors is that they are still being designed with an X86 style opcode pattern. Don't really know whether that's good or bad, but it makes converting between generations easier.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by BasilBrush on Sunday August 31 2014, @08:56PM
The thing about modern 64bit processors is that they are still being designed with an X86 style opcode pattern.
Absolutely not. This is an 64 bit ARM chip. It has nothing to do with X86. The ARM is by design a RISC chip vs the X86 CISC design, and thus by design is completely different.
Of course more modern X86 chips are RISC running microcode to emulate the X86 instruction set. Which still makes is CISC, but in a different and still un-ARM like way.
Hurrah! Quoting works now!
(Score: 2) by HiThere on Monday September 01 2014, @06:03PM
I admit that I don't know much about ARM architecture, but I believe it still basically follows the x86 pattern. In comparison ICL had assembler level instructions that were packed many to a word, and words of varying length. I know this kind of thing is done in microcode with modern CPUs, but that's not the same thing at all.
OTOH, everything has followed a similar architecture in a broader sense since the 1950s. At that time there were even systems with 10 state memories. They worked, but they were slow and expensive in comparison to the binary memories.
If ARM is really RISC on the surface layer, then that isn't something that I expected, so I was wrong. But reading WikiPedia on their instruction set, it seems to be to still be basically x86 style instructions. (Actually, the model I take at the base of the tree is the IBM 7090, but nobody knows that anymore. Or even the Intel 8008.) There ARE different approaches, but none have been successfully developed, AFAIK, for use at the end user level. Even higher level assemblers have failed. There were CPUs set up with LISP, FORTH and Java as assemblers, but they were never generally successful. CDC tried to build a machine with APL at the assembler level, but it was never released (as such, it was released with a simpler assembler). There are probably other attempts I never heard of.
What would be really interesting is a machine with a dataflow implementation at the assembly level. This would take a LOT of work (and I have no idea really just how much) but it would pretty much solve the problem of programming for multiple cores at the end user level. Still, any functional language would have the same capability, but most functional languages solve the problem with immutability, which is nice if your problem can readily be structured that way, but many problems require changeable state. Dataflow comes with a different series of limitations (I'm sure they're there, but the only one I'm sure of is difficulty in wrapping your mind around it), but it doesn't demand immutability. What is does do is make nearly everything lazy.
It's hard to draw boundaries and say "This is where things fall into a different classification", so I guess it's not surprising that we should disagree (unless I'm just wrong...given my ignorance of ARM this is quite possible), but I tend to put the weight on different styles of organization. So I could pure functional designs as one category, and dataflow as one category, and standard procedural as one category. I'd count Object orientation as a separate category, but it doesn't seem to fit into this split. Any of these three categories can be Object oriented, though the benefits differ, and I think that they are largest in the procedural category. Perhaps dataflow would have as great a gain.
To me whether memory aligned access is required or not is a nearly irrelevant detail when deciding which family of designs is being considered. Some RISC designs are of a different family than the x86 family, but by no means all of them. In fact I count most of the RISC designs I've seen as being just ways of optimizing the X86 architecture for slightly different problems. There are exceptions, but none of the ones I'm aware of ever came to market. (Again, I'm talking about the user interface layer, not the microcode, which is, indeed, radically different.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2, Interesting) by Username on Saturday August 30 2014, @07:08PM
Where is my slide out keyboard!?
(Score: 2) by c0lo on Saturday August 30 2014, @10:30PM
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford