Mobile Atom SoC to Remain 32-bit at Least Until 2015

  • Thread starter Thread starter Guest
  • Start date Start date
Toggle sidebar Toggle sidebar
Status
Not open for further replies.
Makes sense that they'd want to repeat the same mistakes they made last decade and create more work for developers. AMD beat Intel to 64 bit, then Intel agrees to use AMD64 as the basis of their own implementation because it was just plain better.

In the mean time, Intel and Microsoft made a secret deal to delay a 64 bit consumer Windows as long as possible so that AMD64 does not give AMD any actual advantage or selling point.

Then there's the matter of how badly Microsoft and ISV's continues to botch 64 bit Windows compatibility to this day... There are numerous documented incompatibilities between Microsoft Office files saved with 32/64 bit versions of Office. Such things are unheard of in Linux/GCC, which properly supported AMD64 from right around the time it came out.
 
So why should I buy one of these over an AMD C-series or E-series APU then? They just have to make Atom suck, right? (which is why I bought an E350 netbook...)
 
Makes sense, honestly. I don't think they need to till 4GB+ RAM starts being used in mobile devices. Till then, why add the 64-bit extensions if they aren't going to be used? From what i know, current CPUs have to emulate a 32-bit environment. Native 32-bit processors wont have to do that. Possible performance advantage? I don't know enough to answer that.

[citation][nom]geezerpleaser[/nom]There are numerous documented incompatibilities between Microsoft Office files saved with 32/64 bit versions of Office. Such things are unheard of in Linux/GCC, which properly supported AMD64 from right around the time it came out.[/citation]
Yeah but even MS recommends using the 32-bit version of Office 2013, and that's what i did with the preview. Does office even exist as a 64-bit version (apart from the current preview/trial version for 2013)?
 
I can also see mention of "Intel Gen 7" graphics, instead of the PowerVR stuff. Wonder what that is. I would assume, looking at the claim they're making about performance per watt, that this is going to be based on Haswell.
 
Isn't the CURRENT Atom 64-bit? The issue was driver support from the Graphics chip. Maybe Intel wants to just keep Clovertrail/Silvermont Atom as 32-bit for now so that they can push Haswell/Broadwell into the tablet sector with their 10 watt SOC parts. Silvermont will be for small form factor tablets that do not need more than 4 GB as well as phones. Haswell/Broadwell will be for large form factor tablets that will do more PC type things along with convertibles (along with desktops, workstations, servers, etc.).
 
omg...
The first two comments on this just shows that they dont know what 64bit is for....

All 64bit is for to access more RAM beyond the 32bit 4gig address barrier....

Nothing more... It gives no performance boost or anything else for that matter...

Back in the old days, the transition from 16bit to 32bit was a giant leap because cpu instructions were too constricted, but that is simply not the case with 32->64...

And since phones don't need to access great big globs of RAM, it makes sense to keep them at 32bit... why bother wasting resources on a phone(especially a phone) that are not needed yet?
 
The first two comments on this just shows that they dont know what 64bit is for....

All 64bit is for to access more RAM beyond the 32bit 4gig address barrier....

Nothing more... It gives no performance boost or anything else for that matter...
Click to expand...

This is not true, a 64 bit program can be a lot faster than a 32 bit program, but as usual the software lags behind the hardware and the advantage of the 64 bits is lost. It also depends on the type of program being run, some maths intensive programs run a lot faster when running 64 bit software.
 
memadmax: Your comment shows that you aren't a software developer, which is how you completely missed the point. Ideally, developers should just be able to release a 64 bit version of their software, but thanks to Windows being so incredibly fragmented between it's 32 and 64 bit variants, you have to test both (and occasionally apply special fixes to one or the other), because it's not safe to assume that just because it works in 64bit Windows that it will work in 32bit(and vice-versa).

It's totally relevant to Atom because the ONLY selling point of x86 is compatibility with the full version of Windows, aka not the gimped ARM version of Windows, which Atom promises to continue perpetuating the need for a 32bit version by being the only 32bit x86 CPU you can still buy...

Make sense?
 
[citation][nom]ojas[/nom]Makes sense, honestly. I don't think they need to till 4GB+ RAM starts being used in mobile devices. Till then, why add the 64-bit extensions if they aren't going to be used? From what i know, current CPUs have to emulate a 32-bit environment. Native 32-bit processors wont have to do that. Possible performance advantage? I don't know enough to answer that.Yeah but even MS recommends using the 32-bit version of Office 2013, and that's what i did with the preview. Does office even exist as a 64-bit version (apart from the current preview/trial version for 2013)?[/citation]it is about time they start support now, so it allow software developer to get some head start. Some high end phones has already come with 2GB of RAM, so it wont take long that we got 4GB models. I dont like the idea of we have 4-8GB of Ram when most developer still stuck in 32bit mode. This is what already happen in desktop.
 
[citation][nom]Tomfreak[/nom]it is about time they start support now, so it allow software developer to get some head start. Some high end phones has already come with 2GB of RAM, so it wont take long that we got 4GB models. I dont like the idea of we have 4-8GB of Ram when most developer still stuck in 32bit mode. This is what already happen in desktop.[/citation]
True, me too really. But think about it, most people aren't using more than 2GB RAM in their DESKTOPS, gamers for now don't really need more than 4GB, only people like you and me have 8GB+ in their rigs.

I've always found the need for >1GB RAM in mobile operating systems indicative of poor optimization than anything else. I mean, Win 7/8 need only 1GB min to run in 32-bit mode, and 2GB in 64-bit. And they're full blown operating systems.

Sure, i'd like to see 64-bit architectures ready for mobile, but at the same time if they offer no advantage at present (possible disadvantage?), i think they there's no point. By 2014/15 i think most of the world's PCs would have transitioned to Win7 at least and 64-bit desktop operating systems should be very common. Then mobile will make the transition too.

I don't remember Apple, Google or MS even talking about 64-bit mobile operating systems. I'm not too sure about the Win 8 Pro tablets, though. Makes more sense for MS, since they want consistency across devices. They might be the ones to eventually push the change to 64-bit. (Doesn't the Surface Pro already have 64-bit Win 8 Pro? it has 4GB RAM, after all...)
 
Interesting stuff from wikipedia:
x86-based 64-bit systems sometimes lack equivalents of software that is written for 32-bit architectures. The most severe problem in Microsoft Windows is incompatible device drivers. Most 32-bit application software can run on a 64-bit operating system in a compatibility mode, also known as an emulation mode, e.g. Microsoft WoW64 Technology for IA-64 and AMD64. The 64-bit Windows Native Mode[23] driver environment runs atop 64-bit NTDLL.DLL, which cannot call 32-bit Win32 subsystem code (often devices whose actual hardware function is emulated in user mode software, like Winprinters). Because 64-bit drivers for most devices were not available until early 2007 (Vista x64), using a 64-bit version of Windows was considered a challenge. However, the trend has since moved towards 64-bit computing, particularly as memory prices dropped and the use of more than 4 GB of RAM increased. Most manufacturers started to provide both 32-bit and 64-bit drivers for new devices, so unavailability of 64-bit drivers ceased to be a problem. 64-bit drivers were not provided for many older devices, which could consequently not be used in 64-bit systems.
Click to expand...

There's more stuff, here: https://en.wikipedia.org/wiki/64-bit

Might also be interesting to note that current desktop processors aren't fully 64-bit either, probably why they're known as 64-bit extensions for x86...

https://en.wikipedia.org/wiki/X86-64

and: https://en.wikipedia.org/wiki/WoW64
 
The Atom core already supports x86-64. Intel just disables this functionality on mobile SOC's. When they see the need to enable this, they will. Let's not forget that there's no 64-bit Android and that a 64-bit environment will probably have a higher power consumption (more registers to feed). Even ARM won't have 64-bit processors out before 2014 and we won't see them in phones before 2015.
 
it's not true that 64bit is faster than 32bit like someone said. quite the contrary. they can be slower. why ? because 64bit means 2 times the memory bandwidth is used, so for a constrained memory bus bandwidth it will take more time. example: if a transfer of numbers in a number crunching app transfered 1GB/sec, if the numbers are 64bit, it will transfer 2GB/sec of data. So if the bus has a limited bandwidth ( like 500MB/sec ) in the second occassion it will take 4 seconds instead of 2.

the only reason to have 64bit in mobile is like someone said, to have more than 4GB of RAM. given the fact that smartphones already have 2GB, I would consider that 2015 is a bit late, 2014 or late 2013 would be a better choice IMHO.

 
Here's some nice 64 bit vs. 32 bit benchmarks, where 64 bit is consistently faster:

http://www.phoronix.com/scan.php?page=article&item=ubuntu_1210_3264&num=1

You see, if you're not a programmer, and not an electrical engineer, don't assume that because you think you have a basic laymans understanding of software and hardware, that you can necessarily understand cause and effect of CPU architecture.... It's complicated, and throw in Microsoft's bad code for some extra "WTF", and anything can happen.
 
Holy sh!t my head hurts.

Ok first off, the difference between "32-bit" and "64-bit" when referring to an ISA is the size of the register stack. A 64-bit register can hold and process a 64-bit value, meaning you can directly read and write to a 64-bit memory address. In 99% of all case's this is strictly a memory management issue as most code doesn't involved 64-bit values and the little that does can use SSE which has it's own 64-bit registers and functions more like a co-processor.

Now with respect to the NT Kernel implementation of x86 and AMD64 ISA's there is a huge gigantic difference between the two. Firstly kernel can not execute non-native code in kernel space, this means the 64-bit NT Kernel is unable to directly execute 32-bit code, this is why kernel mode drivers all need to be 64-bit in order to work in a NT 64-bit system. Now for userland there is WoW64 (Windows on Windows) which is a form of environmental virtualization. This is required as NT 64 and NT x86 are vastly different kernels with different memory architectures. The NT x86 memory architecture was designed back in NT 4.0 days and has remained largely unaltered over the years to preserve backwards compatibility. This has introduced several security and efficiency issues over the years that could not be properly addressed and instead had work-around's created.

With NT x64 MS had a chance to rewrite the kernel code and they took that opportunity to permanently fix many of these issues. This created a form of native sand-boxing and a significantly improved stability and security posture. Right now it's pretty much impossible for an application to crash an NT x64 kernel. Buggy drivers are a different issue as their running in kernel mode and can play havoc on the system, though MS has gone through great strides to try to implement on-the-fly driver resets.

WoW64 doesn't "emulate" a 32-bit kernel as much as it emulated the older NT x86 environment. Applications can still make kernel calls and do everything they could do on a NT x86 system, the WoW64 engine will trap them and emulate them while not letting the application actually talk directly to the kernel. The AMD64 ISA allows for mixed 32/64 bit code execution, so there is no emulation of a 32-bit CPU happening, only the operating environment is being emulated.
 
For the people saying that 64-bit instruction set makes the computer slower and its only purpose is to access more than 4GB RAM, ask yourself: why does gaming console these days use 128-bit instructions?

Most single pieces of data fit in 32 or 64 bits. The benefit of 128 bits is that you can operate on 4 pieces of 32-bit data at the same time, which is called SIMD (Single Instruction, Multiple Data). This is only useful for data that needs the same operation on all 4 pieces, which is common in games for things such as 3D graphical transformations, physical simulation, collision detection, etc. 128-bits is the “sweet spot” of price and performance, so that is what everyone seems to have settled upon.
Click to expand...

from http://insertcredit.com/2007/02/
 



Apples and Oranges.

We're talking about generic computing, SIMD vector instructions are a completely separate component of your CPU. There is a separate register file and instruction set just for the SIMD components, their names are SSE and now AVX / FMA. When talking about x86 vs x64 we're talking the generic ALU / MMC components.
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom