The Upcoming Pixel Tablet Could Ship With a 64-Bit Only Version of Android 13 (xda-developers.com) 32
An anonymous reader quotes a report from XDA Developers: While Apple switched to 64-bit-only support with iOS 11 in 2017, Android still supports legacy 32-bit applications. However, Google is in the process of switching to 64-bit-only support, and last year's Android 12 was the first version of the OS to support 64-bit-only builds. While the company did not make the switch with the recently released Android 13, it is reportedly working on a 64-bit-only version of the OS for the upcoming Pixel Tablet. According to Mishaal Rahman, Google is currently testing a 64-bit-only build of Android 13 for a device codenamed 'Tangor.' For the unaware, that codename refers to the upcoming Pixel Tablet, which the company showcased during its I/O keynote earlier this year. If the Pixel Tablet launches with a 64-bit-only version of Android 13, it will be among the first Android devices to drop 32-bit support. "Dropping 32-bit support on the Pixel Tablet will likely reduce RAM usage, but the tablet won't be able to run 32-bit applications," notes the report. "But that shouldn't be a problem for most users, as all recently updated apps on the Google Play Store offer 64-bit support due to the mandate Google put in place in 2019."
wonâ(TM)t shouldnâ(TM)t (Score:2)
slarshdot havng stronk
Re: (Score:2)
Slashdot still maintains exclusive compatibility with 7-bit characters.
Older versions (Score:3)
Re: (Score:2)
I don't blame you... a lot of modern-day Android applications have become little more than ad delivery platforms. The actual functionality of the application is now a secondary concern.
Re: (Score:2)
If those apps are using the NDK, then yes they'll stop working. If they're using the SDK (i.e., Java) then they'll be fine.
64-bit only affects 32-bit native code apps, but apps still using Java are fine because it's the JVM that gets upgraded.
It's a
Re: (Score:2)
Did you read the summary?
"Dropping 32-bit support on the Pixel Tablet will likely reduce RAM usage, but the tablet won't be able to run 32-bit applications,"
Re: (Score:1)
Re: (Score:2)
I've tend to find apple phones are the ones that lag, with for example, 5ghz wifi (I had to turn 2.4Ghz back on in my parents house for a fairly new apple phone years ago when everything else was fine, and I don't run bleeding edge stuff),
I don't know if that was the phone or the wifi router or both. After all, 5GHz was available with 802.11n in 2003. The last iPhone not to have 5Ghz was the iPhone 4. For me, 5GHz did not work on my home router reliably until I updated the router firmware as it was definitely finicky w
Re: (Score:2)
You're pretty lame as far as trolls go.
Re: (Score:2)
My 64-bit CPU also runs 32-bit applications as long as the OS bothers to include the runtime for it. Of course you'll have two runtimes loaded into RAM. If RAM weren't so precious on mobile (or runtimes so huge) maybe we could continue to have both.
Re: (Score:2)
I think it's more about needing to support the mixed mode stuff. It's an attack surface for malware. It's a business cost that is only justified by needing to support older and lower end hardware.
If ARM CPUs could drop 32 bit support that would be both a cost saving and potentially better speeds too.
Re: (Score:2)
If ARM CPUs could drop 32 bit support that would be both a cost saving and potentially better speeds too.
ARMv9 is 64-bit only going forward; however, ARM cannot control that manufacturers still use ARMv8 32-bit processors. Also there will be a need for 32-bit microcontrollers.
Re: (Score:2)
That's what I mean, the all those SoCs aimed at the low end can drop 32bit support.
increase RAM usage, not decrease (Score:2)
"Dropping 32-bit support on the Pixel Tablet will likely reduce RAM usage, but the tablet wonâ(TM)t be able to run 32-bit applications,"
the size of binaries increases and RAM usage *increases* by recompiling as 64-bit, due to integers and memory pointers being twice as long as they were in a 32-bit program. it is also well-known that power consumption also goes up, by around 10-15%, mostly due to the increased size of L1 cache needed to cater for the larger binary size. if you look at comparative 32-
Re: (Score:2)
But at the same time the 32 bit libraries won't be loaded. Thus overall reduced ram usage for the device. Not necessarily per application.
Re: (Score:3)
it is also well-known that power consumption also goes up, by around 10-15%, mostly due to the increased size of L1 cache needed to cater for the larger binary size. if you look at comparative 32-bit ARM Cortex cores they have 64k L1 cache, but 64-bit ARM Cortex cores all come with 96k.
Going from 32 to 64 bit also pays a performance dividend during any kind of computationally expensive activity. It won't buy you anything when you're doing a bunch of conditional jumps in a row (or not) but when you're processing data then being able to process more per cycle is valuable all on its own. The former kind of processing generally can noodle along at low p-states, the governor will crank them during the latter and then your 64 bitness means you get done being at a high clock rate quicker, and ge
Re: (Score:3)
Going from 32 to 64 bit also pays a performance dividend during any kind of computationally expensive activity. It won't buy you anything when you're doing a bunch of conditional jumps in a row (or not) but when you're processing data then being able to process more per cycle is valuable all on its own.
Generally, it depends on the data you're working with. SIMD should be ignored here, as it was already >32bit.
But ultimately, if the data you're working with is 32-bit, there'd be no advantage in instruction density- normally.
Arm, however, allows an LSR as an instruction operand, actually allowing you to use the data in a packed manner:
LD R0, V1
ADD R2, R0, R0, LSR 32
Without the ability to do that, packed data would require the same amount of instructions as doing it unpacked with 32-bits:
LD R0, V1
Re: (Score:2)
the size of binaries increases and RAM usage *increases* by recompiling as 64-bit, due to integers and memory pointers being twice as long as they were in a 32-bit program.
Recompiling to 64-bit does not automatically make integers 64-bit unless they were explicitly declared that way in code.
Re: (Score:2)
See 64-bit data models [wikipedia.org]
LLP64 uses 32-bit for int and long types in C, and 64-bit for pointers. In Java this makes less sense as JVM already strictly defines the size of integer types and there are no data models.
More exciting to me is "x32 ABI" for x86_64 that uses the ILP32 model on a 64-bit instruction set. But only for user space. Kernel and drivers still uses one of the normal 64 models. But of course this can cause the same multiple runtime issue if you want to give applications the flexibility on which
Re: (Score:2)
Recompiling to 64-bit does not automatically make integers 64-bit unless they were explicitly declared that way in code.
That is true for Windows as they defined long and int as 32-bit and long long as 64-bit. Every Unix derived OS like BSD, Linux, and MacOS uses LP64 defines int as 32-bit and long as 64-bit.
Re: (Score:3)
So what you're saying is that we need to go back to 8-bit CPUs in order to get longer battery life? Alright! Z80-powered smartphones, here we come!
Reminds me of Windows (Score:2)
And the convoluted methods they went through to support 64-bit apps; It's still a mess. For years at the OS level we've had "System32 for 64bit apps" and "SysWOW64" for 32-bit apps, insanity!
Re: (Score:2)
Re: (Score:2)
DOSbox, vDOS/vDOSplus, PCem, or 86Box. If your app needs printer support to work, then I recommend vDOS. From there you can install either Windows 3.11 for WorkGroups, or 3.11 without WorkGroups (yes, that exists).
For an improved experience, Windows XP in VirtualBox or VMware gets you 16-bit support. You might have to enable some optional package or install SP3, I forget exactly how it has to be setup. You can also try enabling NTVDM in your "modern" Win 7/10 system. /online /enable-feature /all /featur
DISM
Re: (Score:2)
Get OTVDM - it combines WINE's ABI translation with MAME's i386 emulator. With it, you can install and run most 16-bit Windows software on 64-bit Windows: http://www.columbia.edu/~em36/... [columbia.edu]
Re: (Score:2)
finally fixed it (Score:2)
better late than never! HA HA