OK, maybe there is something to ARM encroaching on or replacing x86 for many users

pxc

Extremely [H]
Joined
Oct 22, 2000
Messages
33,063
MS demo of Kal-El (quad core Tegra 3) running Windows 8 and MS Word: http://www.youtube.com/watch?v=m-v01cCMauk

MS Office, especially if it includes Outlook, is definitely a killer app. Intel and AMD need to get it in gear by the time Windows 8 is released. Otherwise the battery life alone is likely to hurt x86 laptops badly. This is encouraging with an 8 hour battery life, but that's only with a single core Atom and graphics performance is terrible: http://www.pcworld.com/businesscent...ets_with_intels_oak_trail_processor_ship.html .
 
Mmmmm... Do want. (If only it was solar powered ;))
 
IMHO, Intel's biggest problem is lack of a decent graphics core compared to AMD (not sure how they compare to the cores on the ARM SoC's). They haven't been very serious about Atom up to this point, as back when netbooks were the big thing they didn't have that much competition. But that is changing.

From what I've been reading, they are getting serious about developing Atom on their latest process nodes, and making true SoCs out of them (rather than a low-power CPU coupled to a crappy high-power northbridge like the early Atom boards). If that happens, we may see something like their Pentium 4 -> Core transition, where they went from kind of embarrassingly behind to suddenly pulling ahead and getting better. Even if they're only on par or slightly behind ARM, the binary compatibility advantage could be huge for anything but the lowest power tablets.

Like I said though, I don't know if they can compete in the GPU area.
 
IMHO, Intel's biggest problem is lack of a decent graphics core compared to AMD (not sure how they compare to the cores on the ARM SoC's).
Low power Atoms with built in graphics use PowerVR SGX graphics like many ARM processors, including ones in the iPhone and iPad. GMA 600 is a rebranded PowerVR SGX 535 graphics core, and has 2/3 the performance of GMA 950 used in Atoms that had graphics in the separate 945 series North Bridge.

The 32nm Atom coming out later this year will have graphics performance comparable to the iPad 2. Cedarville Atom is rumored to use the SGX 545, although lower power versions (1-3W TDP models) will probably have the clock speed turned down a bit (or worse).
 
I am never buying another laptop with Intel integrated graphics. They are crap. They need to just partner with NVIDIA.
 
Low power Atoms with built in graphics use PowerVR SGX graphics like many ARM processors, including ones in the iPhone and iPad. GMA 600 is a rebranded PowerVR SGX 535 graphics core, and has 2/3 the performance of GMA 950 used in Atoms that had graphics in the separate 945 series North Bridge.

The 32nm Atom coming out later this year will have graphics performance comparable to the iPad 2. Cedarville Atom is rumored to use the SGX 545, although lower power versions (1-3W TDP models) will probably have the clock speed turned down a bit (or worse).
I think you mean cedarview :)
 
cedarview: yes. A misspelling/brain vacation there. ;)

I am never buying another laptop with Intel integrated graphics. They are crap.
HD Graphics 2000/3000 is decent. Even the previous HD Graphics was competitive with AMD's fastest IGP at the time. /showing blanket statements are dumb

Intel and nvidia have cross-license, technology access agreements (Intel can take from nvidia GPU technology), but the power consumption of an add-on GPU isn't suitable for lower power devices. PowerVR SGX GPUs are the same ones many ARM-based chips includes and when included in Atom chips are competitive against... the ARM competition in both power and performance. :p CPU development cycles are long and any future Atom chips containing nvidia tech are a long ways off. Think around 2013-2014 at minimum.
 
I'm curious how application and driver support will be for ARM. I imagine it will be gimpy at best, much like Windows CE devices of the past. I imagine the ARM support will come in in some form of "Windows 8 Embedded" like they did with XP... it would be really neat though if an ARM could run vanilla Windows 8, I just don't see it happening though.
 
I'm curious how application and driver support will be for ARM.
Driver support will probably be spotty outside of the hardware support Windows 8 for ARM ships with. Devices with generic interfaces (USB mouse/KB, BT, HID, mass storage, etc) should probably be fine. Some random device outside those? Probably not unless the device maker is willing to support Windows 8 for ARM.

The difference between Windows CE and Windows 8 for ARM is that the latter has the same full Windows API support as regular Windows*. A recompile targeting ARM should make the program run on Windows 8 ARM systems (interface problems for tablets, i.e. a mouse interface on a touch screen are different problems). That doesn't mean all applications will be able to run on ARM without significant updating to compile on newer tools, or possibly some will be too old to be worth porting at all.

* I realize that sounds fantastic, and I was skeptical until MS demonstrated what looked like Word 2010 running on ARM in the video linked above. That is definitely not a Windows 8 native application and suggests many or all Win32 APIs have been ported to ARM.
 
* I realize that sounds fantastic, and I was skeptical until MS demonstrated what looked like Word 2010 running on ARM in the video linked above. That is definitely not a Windows 8 native application and suggests many or all Win32 APIs have been ported to ARM.

Not really sure why this is hard to believe as the full Windows API was supported on the Alpha over a decade ago which was a RISC architecture like ARM. I truly don't believe most people understand just how big of a deal Windows 8 on ARM is. When coupled with the new UI this release of Windows enormous ramifications. I think Windons 8 ARM if well executed could be a huge problem for Android on tablets.
 
Not really sure why this is hard to believe as the full Windows API was supported on the Alpha over a decade ago which was a RISC architecture like ARM. I truly don't believe most people understand just how big of a deal Windows 8 on ARM is. When coupled with the new UI this release of Windows enormous ramifications. I think Windons 8 ARM if well executed could be a huge problem for Android on tablets.

Has Microsoft announced that the API is going to be supported? I just want to make sure it's not a gimmick before I get really excited. I mean the Word demo printing was impressive, but for all I know they could've just ported a limited version of word and made a custom print driver
 
We won't have the official word on APIs and feature sets until the Build event starting September 13th.
 
Just installed it on my EVO. Working great for me, but I have awesome 4G at some.
 
I'm getting hit by a huge wave of nostalgia at the thought of ARM competing with x86/x64. It's almost like the good old 80s/early 90s are coming back when you had various architectures competing with each other. I can't wait :D

It's already fun to see Intel scrambling in near-panic after they have been top dog for so long :)
 
I'm getting hit by a huge wave of nostalgia at the thought of ARM competing with x86/x64. It's almost like the good old 80s/early 90s are coming back when you had various architectures competing with each other. I can't wait :D

It's already fun to see Intel scrambling in near-panic after they have been top dog for so long :)

Yep, if there's only one thing that can light a fire under Intel's ass, it's competition. :D
 
I'm getting hit by a huge wave of nostalgia at the thought of ARM competing with x86/x64. It's almost like the good old 80s/early 90s are coming back when you had various architectures competing with each other. I can't wait :D

It's already fun to see Intel scrambling in near-panic after they have been top dog for so long :)

They're scrambling? They don't seem to be scrambling to me.
Releasing a brand new 6 core chip that their 4 core chip from 1/2 a year+ back can compete with on most every day operations doesn't sound like competing.

Releasing a new platform with no modern day tech support (no usb3 , no sata 3) doesn't sound like competition.

I welcome ARM's aren ainto the low powered desktop/tablet arena but I don't necessarily see it as immediate competition.

Intel can't compete in the low powered arena. It's Atom offering has always been sub-par. I'm not sure how ready Intel is to lose that niche market but I severely doubt it will make or break them.

Now if ARM starts taking their desktop ventures further in a few years, then possibly. But they've not even laid their Windows netbook eggs yet. Let's not count the egg's chick's chick's offerings. :p
 
ARM is going to be taking alot of the market place in low power consumption laptops and notebooks/net books., simply because they use so little power with the tegra 3 and im quite sure other companies such as qualcomm will be doing the same as the nvidia tegra 3. both , compaired to intel and amd.who have single core processors, and we are looking at the tegra with 4 cores!
 
Driver support will probably be spotty outside of the hardware support Windows 8 for ARM ships with. Devices with generic interfaces (USB mouse/KB, BT, HID, mass storage, etc) should probably be fine. Some random device outside those? Probably not unless the device maker is willing to support Windows 8 for ARM.

The difference between Windows CE and Windows 8 for ARM is that the latter has the same full Windows API support as regular Windows*. A recompile targeting ARM should make the program run on Windows 8 ARM systems (interface problems for tablets, i.e. a mouse interface on a touch screen are different problems). That doesn't mean all applications will be able to run on ARM without significant updating to compile on newer tools, or possibly some will be too old to be worth porting at all.

Anything written in assembly code is not going to be able to be simply recompiled to target an ARM platform. Games, video editors/encoders, and a whole slew of high-demand applications still have their most intensive components written in assembly code. All of that code is useless outside of x86.

Porting an entire platform is nowhere near as easy as you have been lead to believe it is - my group at HP ended up rewriting HUGE portions of our product when we moved from PPC to ARM. Largely due in part to the fact that almost all our drivers and network code were written in assembly.

I guess what I'm saying is DON'T expect to just pop a Windows 8 CD in some new wave of ARM-based computers and run it like you always have.
 
My observation is Microsoft is doing something sensible here.

1. Windows 8 x86 will continue to support most legacy x86 application, so x86 industry is happy because they feel this is their advantage.

2. Windows 8 ARM will not support x86 application, so x86 indsutry is happy because they feel this is their advantage

3. Windows 8 ARM will survive on its own with new applications, which should be fairly happy to all software makers due to new revenue stream.

4. Because Windows 8 ARM will not support x86 legacy application, we need new software developers to write new software, in this process creating new jobs oppurtunity. Job seekers should be happy.

5. Because all major software makers track Microsoft move, they will need to hire/outsource new software development so that their software can run on new ARM environment. Job oppurtunity!

6. Some companies do not want to commit to such undertaking. You can continue to run them on Windows 8 x86, which will keep x86 industry happy

7. Because some companies do not want to port, if there is viable circumstances, other software developer can find a niche in new environment, job seeking coders, oppurtunity to put food on table...

8. Because Windows 8 x86 and Windows 8 ARM are separated along these lines, they now sits on their partially independent circumstances

8.1 Market acceptance will be there for all to observe. You cannot claim complicated reasons due to one or another, so there is less regret on any party.
 
My observation is Microsoft is doing something sensible here.

I think your points are spot on. Microsoft is hedging its bets with ARM in case Intel can't get x86 power efficiency up to snuff. Metro apps, the new ones, will run on x86 or ARM from a single deployment, in time the Windows Runtime will probably replace Win32, if that ever does happen, which I doubt will be the casein my lifetime.
 
They're scrambling? They don't seem to be scrambling to me.
Releasing a brand new 6 core chip that their 4 core chip from 1/2 a year+ back can compete with on most every day operations doesn't sound like competing.

Releasing a new platform with no modern day tech support (no usb3 , no sata 3) doesn't sound like competition.

I welcome ARM's aren ainto the low powered desktop/tablet arena but I don't necessarily see it as immediate competition.

Intel can't compete in the low powered arena. It's Atom offering has always been sub-par. I'm not sure how ready Intel is to lose that niche market but I severely doubt it will make or break them.

Now if ARM starts taking their desktop ventures further in a few years, then possibly. But they've not even laid their Windows netbook eggs yet. Let's not count the egg's chick's chick's offerings. :p

Oh, we.. i mean, they... are scrambling :) If you look at the cadence of intel products, there's the "tick/tock" cadence, where you refresh the process node and the architecture separately. You can't expect every single product release to be mindblowingly awesome. You might end up getting some O/C headroom if you get a process swap, and that's "free" performance right there.

From a consumer standpoint, though, i think ARM is going to make a splash and then go away in the distant future. If they do have a full featured MS Office "app" on release, it will be a compelling option, as browsers and simple desktop publishing (maybe tack on general media consumption) is 95% of the daily use of a computer for 95% of the people out there. Most consumers aren't going to fall in the enthusiast category like we do.

I'm also interested to see the real world benchmarks of battery life on the higher end/higher speed/higher performance ARM products. If intel were to get very serious about fully integrating atom (chipset/graphics/IO), I think there wouldn't really be much to write about. The performance and legacy support for the IA based chips would just be too compelling.

Furthermore, I'm interested to see what the high performance lines are going to be like coming out of intel in the future, I'd wager that the power consumption will be much better... :cool:

Also, the integrated GPUs from intel have been getting a LOT better (at least in the last generation). They're not great by any means, but for the standard consumer, I'd say I wouldn't cry if I was handed an i5 with integrated graphics...
 
Anything written in assembly code is not going to be able to be simply recompiled to target an ARM platform. Games, video editors/encoders, and a whole slew of high-demand applications still have their most intensive components written in assembly code. All of that code is useless outside of x86.

Porting an entire platform is nowhere near as easy as you have been lead to believe it is - my group at HP ended up rewriting HUGE portions of our product when we moved from PPC to ARM. Largely due in part to the fact that almost all our drivers and network code were written in assembly.

I guess what I'm saying is DON'T expect to just pop a Windows 8 CD in some new wave of ARM-based computers and run it like you always have.

who programs in assembly?
 
who programs in assembly?

Very true.Compilers these days have reached a state where it is very hard to create better ASM by hand and generally isn't worth it. I'd be amazed if any game engine or other significant piece of software still contains any hand-crafted ASM. The only piece of software I am aware of which contains such ASM is the FFmpeg/Libav library but it's only in a few sections and should be trivial to port to another architecture.
 
who programs in assembly?

Embedded guys. Low level.

With RISC architecture you are encouraged to write asm, it is very easy. There are only 4 or 5 instruction types.

Moot point because Microsoft has been honing an API and middleware with .NET.
JIT-compile for everything!
 
Embedded guys. Low level.

With RISC architecture you are encouraged to write asm, it is very easy. There are only 4 or 5 instruction types.

Moot point because Microsoft has been honing an API and middleware with .NET.
JIT-compile for everything!

Erm... all embedded guys I know doing AVR/PIC and ARM (M3/4) development use C-based development environments. ASM is very rarely used if only because it's so hard to maintain and extend.

I'd love to see examples of the contrary, though :)
 
who programs in assembly?

Me. And lots of other low level/embedded guys. Also most video/audio encoding libraries (http://x264dev.multimedia.cx/archives/category/assembly), and some parts of certain video game engines (http://en.wikipedia.org/wiki/Quake_engine#Speeding_up_the_rendering.2C_and_rendering_order).

In fact, x264 is a perfect example of my point.:
http://x264dev.multimedia.cx/archives/142
They too had to rewrite all their x86 assembly for the ARM port of x264.

Erm... all embedded guys I know doing AVR/PIC and ARM (M3/4) development use C-based development environments. ASM is very rarely used if only because it's so hard to maintain and extend.

I'd love to see examples of the contrary, though :)

All of the ROMs on HP servers are written in assembly. iLO is written in a mix of C and assembly.

Most embedded systems have the lowest level stuff like device drivers and sometimes interrupt handlers written in assembly. Significant portions of any RTOS kernel used are also going to be written in assembly. Portions of the NT kernel are written in assembly. Even portions of the Linux and Darwin (aka OS X) kernels are written in assembly.

http://stackoverflow.com/questions/580292/what-languages-are-windows-mac-os-x-and-linux-written-in
http://social.microsoft.com/Forums/is/windowshpcacademic/thread/65a1fe05-9c1d-48bf-bd40-148e6b3da9f1
http://en.wikipedia.org/wiki/Linux_kernel#History

Here is a nice article summarizing the pros/cons of using hand-tuned assembly:
http://asm.sourceforge.net/howto/doyouneed.html#AEN120

tl;dr: Assembly exists and is still used (often in conjunction with referencing an optimizing compiler) where maximum performance is needed.
 
Thanks, InorganicMatter :)

I like the summary on that page you linked to with the ASM pros/cons comparison:
All in all, you might find that though using assembly is sometimes needed, and might even be useful in a few cases where it is not, you'll want to:

minimize use of assembly code

encapsulate this code in well-defined interfaces

have your assembly code automatically generated from patterns expressed in a higher-level language than assembly (e.g. GCC inline assembly macros)

have automatic tools translate these programs into assembly code

have this code be optimized if possible

All of the above, i.e. write (an extension to) an optimizing compiler back-end.

Even when assembly is needed (e.g. OS development), you'll find that not so much of it is required, and that the above principles retain.

See the Linux kernel sources concerning this: as little assembly as needed, resulting in a fast, reliable, portable, maintainable OS. Even a successful game like DOOM was almost massively written in C, with a tiny part only being written in assembly for speed up.

It basically brings me back to my original statement that there are very few situations where a compiler wouldn't best hand-crafted ASM. I have seen the ASM in the OS projects I have been involved in or have taken a look at (ReactOS, NetBSD, Linux) and they invariably use those for the very early bits before the OS has been started, generally for setting the environment (CPU flags/registers, real/protected mode, etc.) and loading initial data.

I think that firmware is often written in ASM due to the lack of space and the difficulty and effort involved in writing and optimizing a compiler for that purpose. Back before compilers generated (proper) SSE code it was also generally accepted to use inline ASM for that.
 
It basically brings me back to my original statement that there are very few situations where a compiler wouldn't best hand-crafted ASM.

Well, there are practical reasons and they begin to become more realistic as you develop on a platform that is mobile with limited resources. Wirth makes a good argument on the subject.

See: Niklaus Wirth, "A Plea For Lean Software", Computer, vol. 28, no. 2, pp. 64-68, Feb. 1995, doi:10.1109/2.348001
 
Well, there are practical reasons and they begin to become more realistic as you develop on a platform that is mobile with limited resources. Wirth makes a good argument on the subject.

See: Niklaus Wirth, "A Plea For Lean Software", Computer, vol. 28, no. 2, pp. 64-68, Feb. 1995, doi:10.1109/2.348001

Hmm... from what I can tell most of the added bloat in applications come from fancy added features, shortcuts and lack of interest in compression. I'd venture to say that you don't need to use ASM to get a lean, mean application. Staying away from bloated frameworks and libraries should help immensely already. Running a C-app using nothing more than some barebones headers and libraries through a good compiler should give very good results in terms of size and performance.

When I use a framework like Qt I know that it'll massively increase of the binaries produced (static compile, adding the DLLs/SOs is even worse), but accept this because of the ease of development it offers. Writing any non-trivial app in ASM is an exercise frustration.

The only times when I'd seriously consider using ASM is when it is the only realistic way around certain limitations or it offers tangible performance benefits. In my daily work as a software developer there are previous few of such moments :)
 
who programs in assembly?

954-not-sure-if-serious.jpg
 
My point is that very few applications are written solely in ASM.

I no longer do any programming but I recall writing my last line of Assembly code on a C-128. After that all my programming was made in pascal, later c and c+ c++ .net.

BTW do you think iphone and adroid apps are done in ASM?
 
My point is that very few applications are written solely in ASM.

Bingo. No one writes in assembler without VERY specific need anymore. Writing large amounts of assembler on modern OSes simply isn't practical and is cost prohibitive.
 
My point is that very few applications are written solely in ASM.

I no longer do any programming but I recall writing my last line of Assembly code on a C-128. After that all my programming was made in pascal, later c and c+ c++ .net.

BTW do you think iphone and adroid apps are done in ASM?

Bingo. No one writes in assembler without VERY specific need anymore. Writing large amounts of assembler on modern OSes simply isn't practical and is cost prohibitive.

No, but to say that nobody does is extremely ignorant.
However in the specific context of ARM, assembly might be less than desirable.
ARM is very ambiguous. Could mean ARMv11 with Tegra; ARMv11 with Broadcom, TI's OMAP... the configuration changes wildly, so therefore we have higher level stuff for portability. This is a given.

However, software bloat and assembly shouldn't be disregarded altogether.
In the Raspberry Pi thread I made the claim I could replace my workstation with a Raspberry Pi to much skepticism. The fact of the matter is that software has been getting bloated for some time and yes, I do contriversially claim that I could replace my workstation with Raspberry Pi/ARMv11 w/ Broadcom. I would just need Debian and a light window manager. All builds take place on mainframe/cluster... nothing really CPU intensive
client side. ~5-10W with peripherals at full load? Take standard 4000mAh laptop battery. You can literally plug away all day. Shut up and take my money.

But with W8 ARM edition? Not so sure.
 
IMHO, Intel's biggest problem is lack of a decent graphics core compared to AMD (not sure how they compare to the cores on the ARM SoC's). They haven't been very serious about Atom up to this point, as back when netbooks were the big thing they didn't have that much competition. But that is changing.

From what I've been reading, they are getting serious about developing Atom on their latest process nodes, and making true SoCs out of them (rather than a low-power CPU coupled to a crappy high-power northbridge like the early Atom boards). If that happens, we may see something like their Pentium 4 -> Core transition, where they went from kind of embarrassingly behind to suddenly pulling ahead and getting better. Even if they're only on par or slightly behind ARM, the binary compatibility advantage could be huge for anything but the lowest power tablets.

Like I said though, I don't know if they can compete in the GPU area.

The specialty of ARM I think is that you can roll out a custom solution in that regard.
Current Atom solutions are two chip and you can get what you want from ARM in a one or two chip solution with about a quarter of the power consumption.

But with Atom you always have the advantage of being x86.
 
Bingo. No one writes in assembler without VERY specific need anymore. Writing large amounts of assembler on modern OSes simply isn't practical and is cost prohibitive.

The only place I can think of where ASM is used often or in brief spurts are video game consoles. You can probably trace it as far back as maybe the NES system and probably earlier to Atari. And, I'm sure some ASM is used in current DS, 3DS, PSP, Wii, 360 and PS3 titles.

A lot of the reasons behind it is because:
a.) You're working with one very specific hardware spec so there is no worry that ASM will break on another console. Can't program entirely in ASM on PC unless everyone uses the same very specific hardware. It helps a lot as another person mentioned above in stuff like video encoding when you want to accelerate encoding speeds using multimedia extensions like SSE or MMX-- something that is commonplace in every x86 processor.

b.) It allows for some game code as someone mentioned above to be optimized. If I can remember, I believe a few games had ASM code to enhance something like data transfer or get direct access to the graphics chip or similar to enhance certain functionality in the game. It was something so specific that a higher level language can't do optimally.​
To give you a very good example: When a game has specific hardware code programmed into it, video game emulators would have to include code specifically for those lines of code to run well in the emulator. You can open up something like ePSXe and look at the various options for specific games that were needed just to run a single game.

Outside gaming consoles, very, very few applications are programmed in ASM unless they are embedded systems, BIOS, or the like. Majority of the applications today are programmed in a high level compiler like C, C++, C# or similar.

Sorry, you installed what? Windows 8?

The only thing I can think of is this:
http://www.xda-developers.com/windows-mobile/guide-installing-windows-8-on-the-htc-shift/

I am unsure if Microsoft ever released a Beta or Alpha of Windows 8 ARM yet. I don't think the Dev Preview has the ARM compatible code in it either, or we would have been reading posts of people installing Win8 on their Android devices.
 
Has Microsoft announced that the API is going to be supported? I just want to make sure it's not a gimmick before I get really excited. I mean the Word demo printing was impressive, but for all I know they could've just ported a limited version of word and made a custom print driver

No. Microsoft has been very cagey whether Win32 ARM development would be possible for third parties.

Win32 on ARM may well be there only to allow MS to put Win32 Office on Win8ARM as a stopgap until they have a Metro Compatible version of Office.

IMO the main advantage of Win8ARM, is lighting a fire under Intels butt to get them producing mobile x86 chips that are more than an afterthought.

As such the latest roadmaps show Intel accelerating the process roadmap on Atom parts until they are in synch with desktop process around 2014, IIRC, on 14nm process.
 
Win32 API is alive and well for ARM as WinRT uses Win32 API:

That doesn't mean you can write Win32 Apps for Win8ARM machines.

It also doesn't mean that just because WinRT is calling Win32 today, that it always will.

Anything written in assembly code is not going to be able to be simply recompiled to target an ARM platform. Games, video editors/encoders, and a whole slew of high-demand applications still have their most intensive components written in assembly code. All of that code is useless outside of x86.

Porting an entire platform is nowhere near as easy as you have been lead to believe it is - my group at HP ended up rewriting HUGE portions of our product when we moved from PPC to ARM. Largely due in part to the fact that almost all our drivers and network code were written in assembly.

I guess what I'm saying is DON'T expect to just pop a Windows 8 CD in some new wave of ARM-based computers and run it like you always have.

Assembly isn't really a serious likelihood for many Windows Applications, MS will make sure the basic drivers are in place. But I agree with main sentiment porting legacy Win32 Applications to ARM has the following issues:

1: Unknown if Microsoft is even going to allow it.
2: Little incentive, even if they do (and still more effort that most think).
3: Massive architecture imbalance compared to what Legacy applications were coded for. Especially in floating point which is approximately three orders of magnitude slower on ARM.

Win8ARM machines will essentially be Metro machines, wether or not there is an accessible Win32 Desktop environment. In practice it will be somewhere between non existent and negligible.
 
Last edited:
Back
Top