git blame shows it's by Bruce's commit 8ff1a275.
However, it's very strange.
I recall we have agreed to move these flags into
build/core/combo/TARGET_linux-x86.mk
and enable it only for x86-atom variant.
I submitted two patches to do that in about Jul-Sep 2010:
https://review.source.android.com/15975
Change-Id: I5310d86e705f23da126c21ecb33a97a074da584a
https://review.source.android.com/16034
Change-Id: I6b7798944bb8262bd83a76712419d8a77d3c34e9
David, JBQ and Ying helped to review and approve them.
Though https://review.source.android.com/ is down now,
I kept all the emails of discussion for the issue in my mailbox.
If you need, I can forward them to you.
I don't understand why these flags re-appear in ICS.
I guess it's probably due to incorrect conflicts resolving process.
Since https://review.source.android.com/ is down,
I could not submit patches now.
Would you please help us to correct it?
Thanks a lot!
Regards,
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
OK...
You mean since ICS "x86" == "x86-atom".
You mean old non-atom cpu are without
MMX, SSE, SSE2 and SSE3 instructions are not supported.
Do I understand you correctly?
This seems to contradict what we have done since
froyo-plus-aosp in Sep 2010.
> I confirm that we had discussions about this when finalizing the IA
> ABI for the NDK, and that we decided that we should give applications
Sorry, who are "we"?
> developers a guarantee that all those instructions are present on all
> IA devices, since they are already present on every compatible IA
> device shipping now or in the foreseeable future.
> From there, bionic can also assume that those are present as a
> minimum, before enabling any further CPU-specific optimizations.
This contradicts what we have decided since Sep 2010.
I recall change 16034 has been merged Sep 10, 2010.
We, all reviewers of 16034, agreed to separate two IA variants:
"x86" and "x86-atom". The latter one contains SSE2 etc
cflags, while the former one doesn't.
All the reviewers of change 16034 are:
......................................................................
Add atom optimization flags
To enable the optimization, set TARGET_ARCH_VARIANT := x86-atom.
Change-Id: I6b7798944bb8262bd83a76712419d8a77d3c34e9
---
M core/combo/TARGET_linux-x86.mk
1 file changed, 7 insertions(+), 1 deletion(-)
Approvals:
Joe Onorato: Looks good to me, but someone else must approve
Chih-Wei Huang: Looks good to me, but someone else must approve
Ying Wang: Looks good to me, approved
Jean-Baptiste Queru: Verified
David Turner: Looks good to me, but someone else must approve
--
To view, visit https://review.source.android.com/16034
Both x86 variants work well on gingerbread and honeycomb
after change 16034 merged.
Is there any mandatory reason to prevent ICS from
running on old non-atom cpu?
The SSE2, SSE3 instructions are only used for
optimizations for functions like memcpy, strcmp, etc.
I don't think they should be mandatory.
So if you want compatibility, please don't make
such an incompatible change.
> JBQ
>
> On Wed, Dec 7, 2011 at 10:48 PM, Beare, Bruce J <bruce....@intel.com> wrote:
>> That appears to have been in there since March.... quite some time.
>> I have no issue with a change to only enable those flags when the ARCH_VARIANT is
>> set for x86-atom.
>>
>> You should also check the NDK's ABI documentation. Some more recent IA instructions are
>> enabled in the NDK -- this was felt reasonable since the target for android was thought
>> to be the embedded market. This does, however, mean that quite old machines will
>> probably fail for some x86 NDK apps.
>>
>> -Bruce
I can confirm ICS does NOT run on Eee PC 701 with Celeron M CPU.
(it's the first x86 platform that android support, did by Dima
if I remember correctly)
I got illegal instructions and kernel panic.
Anyway, thank you for the explanations.
> JBQ
>
> On Thursday, December 8, 2011, Chih-Wei Huang <cwh...@android-x86.org>
> --
> Jean-Baptiste M. "JBQ" Queru
> Software Engineer, Android Open-Source Project, Google.
Anyway, I'll still try to support old non-atom cpu in our ics-x86 branch.
However, you may not be able to run an x86 apk built by NDK
since it contains SSSE3 instructions.
2011/12/9 Jean-Baptiste Queru <j...@google.com>:
> The decision to settle on SSE3 as a base was made by Google as part of the
> process to finalize the IA ABI for the NDK in collaborations with Intel.
> SSE3 has been available for 7 years if my information is correct. This is
> not the full set of Atom instructions, which are not guaranteed to be on all
> compatible implementations.
>
> Sometimes final decisions don't match the progress that gets made during
> development. Actually, that happens all the time. Work at the platform
> level, but once we commit to a public API in the SDK or NDK we're got to
> support it forever. The situation with ARM where we have to support 2
> different ABIs gave us the background to show us why we didn't want to go
> down the same road with IA if we could avoid it. Specifically, guaranteeing
> a wide set of SIMD instructions is important, as code for which those really
> matter tends to be hand-written and making application developers worry
> about which instructions are present isn't desirable.
>
> At the platform level, we still have 2 variants: plain x86 , which only
> assumes SSE3, and x86-atom, which has the full set of instructions.
>
> As far as I know ICS doesn't require Atom, and people have reported success
> running it in vbox on non-atom CPUs. I believe that the emulator supports
> Atom instructions but I'm not sure.
>
> JBQ
>
>
> On Thursday, December 8, 2011, Chih-Wei Huang <cwh...@android-x86.org>
> wrote:
> --
> Jean-Baptiste M. "JBQ" Queru
> Software Engineer, Android Open-Source Project, Google.
>
--
I.3. 'x86'
----------
This is the name of an ABI for CPUs supporting the instruction set
commonly named 'x86' or 'IA-32'. More specifically, this ABI
corresponds
to the following:
- instructions normally generated by GCC with the following compiler
flags:
-march=i686 -msse3 -mstackrealign -mfpmath=sse
which targets Pentium Pro instruction set, according to the GCC
documentation, plus the MMX, SSE, SSE2 and SSE3 instruction set
extensions.
- using the standard Linux x86 32-bit calling convention (e.g.
section 6,
"Register Usage" of the "Calling conventions..." document below),
not
the SVR4 one.
The ABI does *not* include any other optional IA-32 instruction set
extension, including, but not limited to:
- the MOVBE instruction
- the SSSE3 "supplemental SSE3" extension
- any variant of "SSE4"
You can still use these, as long as you use runtime feature probing
to
enable them, and provide fallbacks for devices that do not support
them.
> > On Thursday, December 8, 2011, Chih-Wei Huang <cwhu...@android-x86.org>
> >> To view, visithttps://review.source.android.com/16034
>
> >> Both x86 variants work well on gingerbread and honeycomb
> >> after change 16034 merged.
>
> >> Is there any mandatory reason to prevent ICS from
> >> running on old non-atom cpu?
> >> The SSE2, SSE3 instructions are only used for
> >> optimizations for functions like memcpy, strcmp, etc.
> >> I don't think they should be mandatory.
>
> >> So if you want compatibility, please don't make
> >> such an incompatible change.
>
> >>> JBQ
>
> >>> On Wed, Dec 7, 2011 at 10:48 PM, Beare, Bruce J <bruce.j.be...@intel.com>
> >>>> Thoughhttps://review.source.android.com/is down now, I kept all the
> >>>> emails of discussion for the issue in my mailbox.
> >>>> If you need, I can forward them to you.
>
> >>>> I don't understand why these flags re-appear in ICS.
> >>>> I guess it's probably due to incorrect conflicts resolving process.
>
> >>>> Sincehttps://review.source.android.com/is down, I could not submit
* How could we submit patches to AOSP now?
So far http://review.source.android.com/
is not back. How could you accept Intel's patches?
* According to previous discussion, seems you don't think
the flags are incorrect. Then why do you accept
a patch to remove them now?
Does that mean we can expect old non-atom cpu
to be supported in post-ICS?
2011/12/9 Jean-Baptiste Queru <j...@google.com>:
> Note that with careful reading, there might be a one-character bug indeed in
> the bionic makefile. That might need to be SSE3, not SSSE3. I'll let the
> experts comment.