Illegal Instruction on 32 bit version?

[Evan Langlois]

i'm getting illegal instruction errors from e2fsck and mke2fs, components of busybox. Initially this was in RemixOS, but I grabbed the busybox from android-x86 project iso and got the same response. I grabbed TinyCore Linux and copied the tools (and their libraries) over to the machine with a USB flash device and was able to run that code just fine. This means its not a hardware problem. In all cases I've used tools that are supposed to be 32 bit.

Anyone know what compiler the android-x86 project is using? Maybe its sneaking in some bad code?

The cpu is a Pentium M (Family 6), and the code is supposedly i386, so it shouldn't be encountering any problems.

Anyone else having similar problems?

[Chih-Wei Huang]

I think the CPU is too old to run android-x86.
Read the x86 ABI requirement

https://developer.android.com/ndk/guides/abis.html#x86

(defined by Google, not by us)

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Evan Langlois]

SSSE3?  As a requirement for x86?  What is Google smoking?   The only chips that contain that instruction set are 64 bit aware!   Whats the point of a 32 bit model if you can't target ANY 32-bit chips?

I would say F* Google and make the 32 bit version Pentium4 - allow MMX, SSE, and SSE2,  I think the majority of existing 32 bit systems these days could work with that, which would include the PentiumM/Centrino line.  Following Google's guides, you have to use a 64 bit capable CPU.

[dgdn]

90% of these issues are solved by using an android build that has been
configured / built with a 64 bit kernel and a 32bit userspace(libs)....many discussions and builds in these
forums and else where...FWIW

[DDS Central]

ABI requirement is specified by Google and all apps with x86 native binaries adhere to it. Even if you force the base system to run on incompatible CPU, third party apps with x86 native code will not run because of incompatible ABI. And I doubt the Houdini ARM translator would work either.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Evan Langlois]

Are there really a huge number of x86 binary applications/libraries?  I would assume they would all be x86_64.   The x86 ABI by itself is taretting machines that DON'T exist.  There are no 32-bit CPUs with that set of instructions. 

@dgdn: WHAT?   A 64-bit kernel isn't going to solve this at all as the kernel would crash in the instance I'm describing.  While I agree that mixed 32/84 might be more efficient on small systems, thats a whole different ABI in itself.  In that case, 64 bit instructions and all your media extensions are available in the ABI, but your pointer size is 4 bytes instead of 8.  Great target for Android where no one app needs more than 4GB of address space as you save on some RAM and run a bit faster since things fit in the cache, but your userspace has to be 4-byte pointer aware, which means Android's x86, not x86_64, and now you've cut-off the ability to use 64-bit extensions to move 64-bit data.  

I think Google was short-sighted here and should have had a P4/Pm ABI for 32 bit chips and a x86_64 ABI that is 64bit data and 32bit pointers with a 64-bit kernel.

Can someone name ONE machine that Google's x86 ABI makes sense for?

[Povilas Staniulis]

Yes there are no 32 bit only CPUs with SSSE3. But all 64 bit capable
CPUs can run 32 bit code natively.
Considering that many low-power x86 machines (primary target for x86
Android) come with only 1 or 2 GB of RAM, it makes no sense to use a 64
bit userspace.

As for apps, there are many apps with x86 support. To mention a few: MX
Player, VLC, Chrome, most Gameloft games.
Haven't seen any apps with x64 natives yet (yes, I did actually examine
APK files)

> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to android-x86...@googlegroups.com
> <mailto:android-x86...@googlegroups.com>.

> To post to this group, send email to andro...@googlegroups.com

> <mailto:andro...@googlegroups.com>.

[Evan Langlois]

I fully agree that if you are low on RAM, 64-bit pointers don't make sense.  The problem is that Google made an x86 ABI that is not x86 at all.  I have found what they are targetting.  Let's start calling this what it is!  The ONLY chip that is a sensible target are low-end Atom processors for netbooks.  They support SSSE3 but not SSE4 nor 64 bit instructions.   It should be called the Atom-ABI.  Google is targetting "What x86 chips are in a phone/tablet?"   However, for Remix, Phoenix, and basic Android-x86, we are more concerned with desktop CPUs, and I think a disproportionate number of people will be looking to run a smaller, lighter OS on older hardware or a second "old" machine rather than buying a new machine for running Android.   New machines that can support full blown desktop apps will likely continue to run desktop OSs as these machines have better application support for desktop-type tasks.  This means a certain bias towards older chips, some of which may be 32-bit WindowsXP machines where the user is realizing that the machine must be retired or given a new OS because application support in the Windows world for 32bit binaries is basically dead and the OS is now totally unsupported.   Android promises a java-based environment where the application code doesn't necessarily have to abandon 32-bit users.  They may not be able to play HD movies because the players use native x86 code, but we can make these systems usable for other tasks.

Google's ABI spec leaves out all the "true" 32 bit x86 chips that don't have SSSE3 (literally ALL desktop CPUs), and fails to allow 64-bit capable systems to use 64 bit instructions (and I mean instances of 64 bit integer data operations, disregarding pointer size).   A true 32-bit x86 ABI should disregard the SSSE3 as its basically Atom-only, and I would contend that 64-bit code should be 64/32, as in "-march=x86-64 -msse4.2 -mpopcnt -m32 -mtune=intel".  allowing 64 bit code with SSSE3, SSE4, etc, and all 64 bit operations, but with a 32 bit pointer size for user-space.  Kernel would be 64 or 32 bit depending on the hardware and overall RAM size.  This only hinders programs that need access to more than 4GB of data, but in most cases, you can split the application such that different pieces run in different processes and share data via Binder - and even then, that would be for large apps that don't currently exist on Android.  Obviously, Google didn't so it this way because they are targetting phones/tablets.

So, here is a proposal.   Let's redefine a few things.  The typical "64-bit" Android-x86 build should be a 64/32 system (as above) advertising a single ABI ("x86") using a "64 bit aware" kernel-space, libraries, and framework.  The only drawback is native code from Play won't use SSE4 unless it dynamically detects it.   If there aren't many apps using x86_64 as you say, this isn't much of an issue.  I bet any author that is using x86_64 has an x86 version as well and could be convinced to autodetect 64 bit instruction sets, SSE4, etc.  However, label this as being for "64 bit" systems, but advertise "x86" ABI to Play store, etc.     That makes for a nice, unified x86 platform.  That frees up the term "32 bit" for people with actual 32-bit systems!  Old Atom CPUs without 64 bit or SSE4 support would use the 32 bit version, but without SSSE3 support (unless someone thinks there are enough people with these chips to add a special "Atom-build"), with non-Atom 32-bit chip users made aware that apps from Play store that use native code may simply fail.   What I'm saying is, drop everything down 1 step.  The "64-bit" version of Android-x86 should use the "x86" ABI, but be compiled with 64 bit instructions, but definately have a "real 32 bit" version without the SSSE3 (some native code from Play may crash, but at least we got partial support).  

> <mailto:android-x86+unsub...@googlegroups.com>.

[Chih-Wei Huang]

Well, you should understand the ABI requirement defines
the minimal instructions sets instead of the maximal or
exact instructions sets that the CPU has to support.
So your argument (no CPU has the exact instruction sets
defined by Google) doesn't make sense.

Android-x86 is just a small community based open source
project that has no any connection with Google.
We have no ability to define or change spec.

There are some attempts to build android-x86 image
without SSE3 instructions, say
https://sites.google.com/site/twisteroidambassador/android-x86/kitkat-non-sse3-build
But without the upstream support (i.e., Google),
it's really hard to maintain that.

Anyway, please send your complain/suggestion to Google if you want.
But I don't think there is any chance to change it.

>> > <mailto:android-x86...@googlegroups.com>.

>> > To post to this group, send email to andro...@googlegroups.com
>> > <mailto:andro...@googlegroups.com>.
>> > Visit this group at https://groups.google.com/group/android-x86.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.

> Visit this group at https://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[Evan Langlois]

I think you missed my point.   And I'm not stupid - please don't infer that I don't understand that a CPU can support more than the minimal spec.  The problem is that no CPUs support the minimal spec without being 64 bit.   Don't call an OS "32 bit" if it doesn't run on ANY 32 bit chips!  My argument that a CPU doesn't support the specific ABI requirements is this:  What is the purpose of the x86 ABI?  If the purpose is for chips that don't support 64-bit instructions, then these chips don't support SSSE3 either (except Atom).   So, I ask, what is the purpose?   You could make an argument that RAM constrained systems and systems with smaller caches might run better using 4-byte pointers, in which case a mixed 64/32 would be nice.   However, that still requires a 64 bit system, so don't count it as 32!!

Yes, Android-x86 can not change the spec from Google, but you are under no obligation to follow it either!  You need not compile the 32bit OS with support for SSSE3 code just because Google says so.  Android-x86 and Remix are both supplying 32-bit binaries that don't run on 32 bit desktop systems because Google's x86 ABI targets the ATOM chip.  Omit the compilation flag and open up a huge number of desktop chips into the x86 ABI with the caveat that some native binary code supplied with Play-downloaded apps may fail, but all the Java code can work fine on these OSs.

Otherwise, what is the point of the 32-bit release?  What chips are you targeting? Who is your target audience?  Google's target audience for the x86 ABI was older Atom powered devices, which is likely NOT the target of any version of Android-x86.

Twisteroid seems to think that SSE3 and SSSE3 are the same, or they are targetting even OLDER chips without SSE3 either.   I don't believe there is all that much assembler in the OS that the patches would be much more than CFLAGS (as a quick scan of Twisteroid's site confirms).  Why would this require support from Google for a CFLAGS change?

You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/AIGZe_q348s/unsubscribe. To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com. To post to this group, send email to andro...@googlegroups.com. Visit this group at https://groups.google.com/group/android-x86. For more options, visit https://groups.google.com/d/optout.

[DDS Central]

All modern Atoms (Bay Trail or later) are 64 bit capable.

> <mailto:android-x86+unsubscribe...@googlegroups.com>.

> To post to this group, send email to andro...@googlegroups.com
> <mailto:andro...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.

[Evan Langlois]

Thats correct.  However, find a chip that lacks 64 bit extensions but has SSSE3 instructions.  Only older ATOM Diamondville chips fit the bill (unless you know of another).   And this totally illustrates my point.   The 32 bit ABI only supports a VERY tiny number of actual 32 bit chips and NO desktop chips.  Yes, there are plenty of chips that can run the x86 ABI, but these chips are 64 bit capable as well.  So if someone downloads the "32 bit version" of a desktop OS, why do they need a 64 bit capable chip?

You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/AIGZe_q348s/unsubscribe.

To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

[Mike]

Can I ask as, Really Kind of Stupid on what your talking about, I'm An Old School Assembly (Machine Language, If that dates it for you), Programmer, I'm Kind of Confused, About, What your Issue Is?  SSSE3 is A Chip Coding? No?  I Mean We Can't say. SSE3 SSSE3 or Whatever, And believe I've had (and still have) very old laptops, with 3 GB Ram, And A Small Processor, that runs Android-X86 4.4RC2, Like a Champion!

Not trying to cause issues here, Just trying to understand... If you want the older stuff to work, Use An Older OS, Hell For a While I had WIndows 98 installed here, Just for old school stuff (and Ya It was INSTALLED, NOT VM'D 8-)  )

Anyway this is a mail list, so just asking...

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

[Chih-Wei Huang]

The issue is more complex than you think.
It's not that easy to just adjust the CFLAGS.

Twisteroid's patch is for the old 4.4-r1.
I'm even not sure if it's applicable the the latest kitkat-x86
(4.4-r5 release). Let alone the newer releases.
Nobody has succeeded to do it for the lollipop or later releases.

In doubt, you can try yourself to see if it's so easy.
But please search the list to see how many discussions
or attempts of this issue before you begin.

[DDS Central]

I don't know why Intel included x64 support even in low-end Atoms, considering that most devices using them run 32 bit OSes and have no more than 2GB RAM.
I guess they didn't want to make separate cores for different Atom versions (there are desktop Atoms as well).

To unsubscribe from this group and all its topics, send an email to android-x86+unsubscribe@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Evan Langlois]

It's simple.  Pretend I'm average user.  I hear about this new OS to let me run lean/thin Android on my computer.  I visit the site, I click "32 bit" because I know my machine is old.   And ... it doesn't work.   Why not?  Well, only 64 bit chips support the SSSE3 instructions called for in Google's ABI.  SSSE3 are 64 and 128 it "vector" instructions (aka SIMD) that don't exist on 32 bit chips.  But 90% of the apps are written in Java with machine code generated on the fly, so there isn't really any good reason why we need to restrict things like this.

If we can't (or won't) support 32 bit chips, then take down the links to 32 bit builds because its a lie and stop wasting people's time.  Label it as something else because 32 bit chips can't run it!    Define "very old laptop" - what chip does it have?  I bet with 3GB of RAM it has 64 bit instructions.   It may even support the full "Android x86_64" specs.  My old HP laptop does!

RE: "Use an older OS" ... actually, the problem is that a number of people have older hardware and have been trying to do exactly this, but support has been dropped for 32 bit systems by just about everyone.  Ex: Chrome stopped 32 bit at Chrome 50.  You just can't get apps for older systems!  Java JIT and AOT compilation allows us to support just about any chip we want, and Android-x86 is positioned to take over a huge number of systems that would otherwise be "obsolete" and make them usable again.  But it appears Google is mandating against it.  

And if thats the way its gonna be, fine, but don't call it a 32 bit download!  Call it something else.  Call it a "Legacy Systems" download, but if it doesn't run on 32 bit chips, then its not 32 bit!

[Mike]

ok I get that and yes Luckily the old laptop Dell Intel 1505, has SSE3 Instruction set, BUT that's a Code in the chip, It's Fully 32 Bit, with Absolutely NO OpenGL, But still runbs everything Like a champ....

I mean, I get what your saying, My Dad sent me his Old Desktop and it has V-TI (TE?)  I was Like HELLLLL YEESSSSSS!!!!

SO Ya I get it, But 4.4RC2 (Or Higher According to C.W.) Runs Great, But, Ya the SSE3 Is A Code Made In a chip, It's like Me Trying to Program ML With C-64 Memory Address' On A Mac... It won't work...

Unless I'm missing Something. It's the Chip Designers. Not X86... X86 is trying to Adapt to THEM.... Not the Other Way...

Just my Opinion... I'm more then likely wrong...

Mike

[Chih-Wei Huang]

You are keeping emotional and annoyed.
What benefit do you get if we take down the 32-bit image?
Does it solve your problem?
If you can't keep the discussion rational and
constructive, please don't waste your time here.

Indeed my favorite approach to conquer this issue is
to trap and emulate the invalid instructions at kernel level.
This also solves the apps built with Google x86 NDK.
There is one patch to emulate SSSE3 instructions
and it has been applied to our kernel

https://es.osdn.net/projects/android-x86/scm/git/kernel/commits/8609c23d9fd27a3b13786f0cdea1c24adafca24d

However, apparently it didn't solve the problem totally
probably because it's not complete or perfect.
Currently none of our developers have
the expertise to improve it.
If anyone want to clear it up, raise your hand.

>>> > <mailto:android-x86...@googlegroups.com>.

>>> > To post to this group, send email to andro...@googlegroups.com
>>> > <mailto:andro...@googlegroups.com>.
>>> > Visit this group at https://groups.google.com/group/android-x86.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Android-x86" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

[Mike]

*Hand Raised* Oh Wait, N/M Lol 8-)

[Mike]

Sorry to beat a dead horse...

http://softpixel.com/~cwright/programming/simd/sse3.php

On 11/17/2016 8:13 PM, Evan Langlois wrote:

[Evan Langlois]

In my particular argument, it's not SSE3, but SSSE3 that is the issue.  There are 32 bit chips with SSE3, but none with SSSE3.

The lack of a particular instruction set isn't an issue when you are compiling from a high-level language.  In the case of C, you recompile and tell the compiler not to target that instruction - no source changes are required.  In the case of Java, you can distribute the Java code and run it anywhere.  In the case of Android, you send device-neutral java bytecode and it's converted to the actual native CPU code on demand.  The author doesn't need to know anything about the target.   So ... its not as hopeless as your Commodore assembler on a Mac (although the Mac could run an emulator ... there is a C-64 emulator for Android phones as well - works great!).

The only thing that would be a potential snag, and I think this is the issue, would be the ART translator that translates the Dalvik/Java bytecode into native code.  It would generate both SSE3 and SSSE3 code.  Under KitKat, they had a relaxed ABI requirement (I think) and code generation was more on-demand rather than ahead-of-time.  And (I think) the old Dalvik VM didn't generate SSSE3 and you could tell it not to use SSE3.  It looks like they eventually dropped support for lesser machines.   Of course that's a brief glance assessment only.  Rewriting the ART code generator isn't a project I want to undertake for my Aunt's ancient tough-book.  The Twisteroid project might work, but I'd have to graft in the Open version of Play Services and provide alternatives for many of the Gapps.   That may be my next move.

My point is that all these "32 bit" downloads that won't run on any 32 bit CPU is silly.  Rename it to "Legacy" for machines such as older AMD machines (Athlon64, K8, etc) and Intel Core2 machines (all other Intel machines can run the x86_64).  Its only going to confuse people and turn them away and generate tons of bug reports that don't apply.  

[Mike]

You know, Ok I agree With That, When I first started with the X86
Project I was SO LOST, I download atleast 5 ISO's thing Hey This one
will work, I even went for The Old 2.2 Back then, But there is a
learning curve here, I really do get what your saying, and Believe I
have Froyo, CC64, AIAB, All on my computer and have back to the old one,
I still go in and program some ML to Crack some images, just for sh!t's
and Giggles...

But You can't change the chipset... I Agree it's stupid, Hell I
Thought that 20 Years ago. That there should be a Basic STANDARD to ALL
Instruction Sets, Why Should me, At 48, Have to learn a new way, Or
learn to use a A Lesser Language, To get what I want done?? To Me ML Is
the language, But Computers have gotten so "FAST" that no one cares that
every code you use must be decompiled before it runs, and that equals a
slow done, regardless of how FAST the Computer is....

JUst my 2 cents bro, I get it, But I've had to adapt to it (For a LONG
TIME) Just saying, And Honestly trying to help...

Mike

[Mike]

And I have a Few "Legacy" builds on my forum. But you'll have to ask RBG how they work...

On 11/17/2016 9:07 PM, Evan Langlois wrote:

[Evan Langlois]

I am only emotional when you pretend like I don't know what I'm talking about.  Give me the benefit of the doubt!  To me, assuming I don't know something really basic is disrespectful.  Show me respect and I'll do the same, I promise!

I am annoyed that something says "32 bit" and doesn't run on 32 bit processors, thus wasting a LOT of prep time.  I wouldn't have even started this horrible project.  I actually ended up taking the laptop apart - an insane toughbook -  to clear the BIOS password so I could inspect all the settings that might have been causing the errors because I assumed 32-bit meant 32 bit!  While making room for Android, gparted hung and corrupted the NTFS partition so I had to rescue the data and reinstall Windows from the original OEM disks ... which gave me Windows 2000 and NOTHING I have will run on it!  I finally had to find a copy of Windows XP and install all the drivers one by one, one of which was bad and blue-screened.  Plus, the USB port on this is 1.1 and you can't boot off of it.  The only blank CDs I have are black and the CD-ROM is apparently racist because it doesn't like black CDs.  Taking down the 32 bit image doesn't solve the problem, but it stops me from going 12 miles down the wrong road for no reason whatsoever!   If you follow Google's x86 ABI, then "32 bit" is a lie and I fell for it!   So save the next guy days of frustration and rename it from "32 bit" to "Legacy".

The patch to emulate the missing instruction was something I thought of since we used to that back in the old days when you didn't have a math co-processor.  Its basically the same thing, but I didn't think anyone had already done it!  I will DEFINATELY look at the patch!  Thank you for that!   I probably don't have the time to debug it,  but that at least gives some hope!   What sort of issues have you had so far, and how bad is it?  Will it make Android x-86 boot to the Launcher?  And does plain Android x86 have this patch included?   If so, we're back to my original post at basic file utilties crashing trying to make the data.img with an illegal instruction (and copying linux tools from a 32 bit Linux distro to make it work).   I'm wondering if I want to grab one of the older Android KitKat ISOs that are supposed to work on older P4 machines and give it a try, or if I should stick your kernel patch into a "32 bit" Lollipop or Marshmallow build like Phoenix or Remix.  Recommendations? 

I have limited bandwidth so I have to wait until 2AM to do downloads.

[Mike]

Ok

I Got one for you...

Anything Higher then 16-Bit Is a Lie...

--

[Mike]

And to be Honest 16 Bit is a Lie too, But we wont go there...

On 11/17/2016 9:30 PM, Evan Langlois wrote:

--

[Mike]

Just cause you can "FILTER" more bits through a processor doesn't MAKE it a 64 BIT., to be honest there is no such thing, hence, the instruction sets...

[Evan Langlois]

Sorry to beat a dead horse (there isn't much left of poor Wilbur anymore), but ...

No - I think you misunderstood!   I spent years on a "16 bit" m68K ... which has 32 bit ints and 32 bit registers, so I know what you mean.  Register size, bus width, instruction length, int size, pointer size, and all sorts of things are all separate entities and you shouldn't just classify something based on a single number.   However, if the download says "32 bit" you would assume it would work on SOME IA-32 architecture chips!  Technically, it doesn't use 64 bit/IA-64 instructions, but it uses SSSE3 (note the extra S) which don't exist on *ANY* 32 bit chip (except a couple old Atoms).  So ... the "32 bit" build won't run on any desktop 32 bit chips? 

I'm not saying someone should change the hardware or anything else like that.  That's insane!  I think we've discovered that the real reason we can't (easily) support an actual 32-bit system is a combination of apps using native libraries, such as Gapps, and the ART code converter.  

You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/AIGZe_q348s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

[Mike]

Ya, Makes Perfect Sense, BUT, We Can't change it, Way Back In the day, I asked the same question, why Isn't it working, And It Boiled down to I Didn't Have a Code Set For the (Attached  by Lead) Chip, So I was Stuck.. How I ended up with 4.4RC2 and never left it....

Your not going to be able to change it, hell, I wish you could, but "Tech" is moving forward, To Bring it back to what it actually should be, would require a compiler, and, with that your already off the proper course?!?!?! 

Dunno, Just my thoughts, when you started talking about it, I get it, But gave up....

Mike

[Evan Langlois]

What do you mean we need a compiler?  Android is open source and we have the compiler.  We have the compiler, and we have the source.  We CAN change it.  The main question is if we have the resources to modify the ART code generator.

[Mike]

+10

Much better example.

Sent with AquaMail for Android
http://www.aqua-mail.com

On November 18, 2016 9:56:47 AM dgdn <rbg...@gmail.com> wrote:

> Can someone name ONE machine that Google's x86 ABI makes sense for?

no machine, BUT it makes sense for any Intel CPU developed since about 2007

and whereas Googles Android was released first around 2008 it works very well

on both x86 and x86_64 CPUs developed in that timeframe through today, using

either pure x86_64 or 64 bit kernel with 32 bit user space.........

I have 2 machines with Pentium M / 6 and both run 64/32 fine without issues....

I have an i3 machine and it runs x86_64 fine......
I have an Atom (Intel Atom N455)machine that runs fine...

All 4 machines run android-x86 & Remix OS without issues....

should today's Fords engine work in a Model T???? 

CPU's before then should just run Linux cause they are NOT supported by Googles Android.....and/or

redesign Android for your specific case...after all it's open source!!!!

On Thursday, November 17, 2016 at 12:42:54 PM UTC-5, Evan Langlois wrote:

Are there really a huge number of x86 binary applications/libraries?  I would assume they would all be x86_64.   The x86 ABI by itself is taretting machines that DON'T exist.  There are no 32-bit CPUs with that set of instructions. 

@dgdn: WHAT?   A 64-bit kernel isn't going to solve this at all as the kernel would crash in the instance I'm describing.  While I agree that mixed 32/84 might be more efficient on small systems, thats a whole different ABI in itself.  In that case, 64 bit instructions and all your media extensions are available in the ABI, but your pointer size is 4 bytes instead of 8.  Great target for Android where no one app needs more than 4GB of address space as you save on some RAM and run a bit faster since things fit in the cache, but your userspace has to be 4-byte pointer aware, which means Android's x86, not x86_64, and now you've cut-off the ability to use 64-bit extensions to move 64-bit data.  

I think Google was short-sighted here and should have had a P4/Pm ABI for 32 bit chips and a x86_64 ABI that is 64bit data and 32bit pointers with a 64-bit kernel.

Can someone name ONE machine that Google's x86 ABI makes sense for?

--

[dgdn]

> Can someone name ONE machine that Google's x86 ABI makes sense for?

no machine, BUT it makes sense for any Intel CPU developed since about 2007

and whereas Googles Android was released first around 2008 it works very well

on both x86 and x86_64 CPUs developed in that timeframe through today, using

either pure x86, x86_64 or 64 bit kernel with 32 bit user space.........

I have 2 machines with Pentium M / 6 and both run x86 & 64/32 fine without issues....

I have an i3 machine and it runs x86 & x86_64 fine without issues....

I have an Atom (Intel Atom N455)machine that runs fine...

All 4 machines run android-x86 or x86_64(32) & Remix OS without issues....

[Fuseteam]

ohw........it doesn't support actual 32bit devices.........and here i thought i would be able to run android-x86 on the Dell Latitude d630.............why did i waste months of my time on this orz

[DDS Central]

It does but not really ancient ones with CPUs lacking the needed instructions.

On Mon, Aug 13, 2018, 21:24 Fuseteam <gurt...@gmail.com> wrote:

ohw........it doesn't support actual 32bit devices.........and here i thought i would be able to run android-x86 on the Dell Latitude d630.............why did i waste months of my time on this orz

--