Hi! I'm interested in what has to happen for a (presumably) pretty small company to supply such an integral piece.
It seems to me like everyone from Qualcomm over Android to manufacturers would want this. Why did you have to build it instead of them? And is Xiaomi the entity licensing it from you? Does this mean that there will likely be implementations of the Snapdragon 8 Gen 3 that don't support 32 bit apps?
Is this just such a niche problem because most phones have been on 64-bit processors for so many years so that vendors expect the compatibility breakage won't be too big?
How did you anticipate this issue and how are you using the situation? i.e. do you already have experience/contacts in the industry?
Phew, that's a lot of questions and I get it if you don't want to answer all of them. Thanks for your time and stopping by!
When ARM released AArch64, it was a completely new instruction set rather than an extension of the existing 32-bit ISA (like x86-64). AArch64 is a much better designed ISA than AArch32 and supporting both in hardware effectively doubles the complexity of the instruction decoder, so it was clear that eventually there would be AArch64-only CPUs (as there are today).
The technology behind Tango started as a research project while I was doing my PhD. After finishing my dissertation in 2016, I looked into opportunities to commercialize it by contacting every company that was building or planning to build an AArch64-only CPU. There are sufficiently few that it is easily doable even for a small company.
Building a production-ready binary translator is technically challenging and requires a lot of work. The difficult parts are achieving high performance (Tango scores within 10% of native 32-bit execution on benchmarks), low latency (using AOT translation to accelerate startup times) and compatibility (Tango was tested against the top 1000 Android apps and works with all of them).
Already by 2017, Tango was capable of translating AArch32 Android applications. At that point it makes more sense for companies to license our technology rather than developing their own implementation from scratch.
The first commit in what would eventually become Tango was all the way back in 2014, so this project has been in development for a long time. As such there have been many technical challenges.
One challenge that particularly comes to mind was dealing with anti-emulating/anti-debugging code in various Android applications. These apps would do all sorts of crazy things like attaching to themselves with ptrace, installing bizarre seccomp filters which check for specific 32-bit syscalls and using self-modifying code without proper cache flushing to check for the presence of an instruction cache.
The solution for each of those was to emulate the relevant functionality well enough to trick these apps into thinking they were running natively. Although in the case of self-modifying there was no good solution and we ended up hard-coding some particular instruction sequences in the translator for special handling.
One thing that really made the above possible is that for Tango v2.0 we re-wrote a large part (~half) of the codebase in Rust, which was previously entirely written in C. In particular, the ptrace emulation code needs to maintain a lot of internal state about traced threads. This requires maintaining complex data structures, and the ability to easily use enums, Option, HashMap, etc, is a huge help for this.
> One challenge that particularly comes to mind was dealing with anti-emulating/anti-debugging code in various Android applications
While I don't care or want to digress into the ethics of this suggestion, if you had the expertise, wouldn't it be significantly more valuable to author automation APIs for TikTok, Snap, Instagram, Messenger etc.?
The "proper" solution would be for apps to support 64-bit, at which point they can just run natively on the device. The whole reason Tango is required is that there is still a large number of apps that use 32-bit native libraries. This is particularly true in markets such as China which don't use the Google Play Store.
It seems to me like everyone from Qualcomm over Android to manufacturers would want this. Why did you have to build it instead of them? And is Xiaomi the entity licensing it from you? Does this mean that there will likely be implementations of the Snapdragon 8 Gen 3 that don't support 32 bit apps?
Is this just such a niche problem because most phones have been on 64-bit processors for so many years so that vendors expect the compatibility breakage won't be too big?
How did you anticipate this issue and how are you using the situation? i.e. do you already have experience/contacts in the industry?
Phew, that's a lot of questions and I get it if you don't want to answer all of them. Thanks for your time and stopping by!