Slashdot Mirror

How so? ARM processors are quite plentiful and support several operating systems already. Perhaps you're just not very familiar with them. Not to worry. There's plenty of material available.

If you compile the same program in a high level language for a complex processor and a simple processor, they'll produce the same result. Each operation on the complex processor may correspond to several instructions on the simple processor, but ARM's bet with big.LITTLE is that reduced power consumption in a simple processor's instruction decoder makes up for that difference.

For big.LITTLE, the difference between the instruction decoders isn't an issue of different instruction sets; to quote their big.LITTLE Processing with ARM Cortex-A15 & Cortex-A7 white paper:

The central tenet of big.LITTLE is that the processors are architecturally identical. Both Cortex-A15 and Cortex-A7 implement the full ARM v7A architecture including Virtualization and Large Physical Address Extensions. Accordingly all instructions will execute in an architecturally consistent way on both Cortex- A15 and Cortex-A7, albeit with different performances.

so each instruction on the complex processor would correspond to the exact same instruction on the simpler processor.

As that paper says, "It is in the micro-architectures that the differences between Cortex-A15 and Cortex-A7 become clear."

According to the paper, it looks like biggest novelty is... DRM. The optimizer code will be encrypted and will run in its own memory block, hidden from the OS.

DRM is already fully supported in ARM processors. See TrustZone, which provides a separate "secure virtual CPU" with on-chip RAM not accessible to the "normal" CPU and the ability to get the MMU to mark pages as "secure", which makes them inaccessible to the normal CPU. Peripherals can also have secure and non-secure modes, and their secure modes are accessible only to TrustZone. A separate OS and set of apps run in TrustZone. One DRM application of this is to have secure-mode code that decrypts encrypted video streams and writes them directly to a region of display memory which is marked as secure, so the normal OS can never see the decrypted data. Another common application is secure storage for cryptographic keys, ensuring that even if an attacker can acquire root on your device, he can't extract your authentication keys (though he can probably use them as long as he controls the device, since the non-secure OS is necessarily the gatekeeper).

Nearly all mainstream Android devices have TrustZone, and nearly all have video DRM implemented in it. A large subset also use it for protection of cryptographic keys (Go to Settings -> Security and scroll down to "Credential Storage -> Storage type". If it says "hardware-backed" your device has TrustZone software for key storage.

So, no, nVidia isn't doing this for DRM. That problem is already solved, though it's stupid because all of the content is on the Internet anyway.

Or even better: ARM Versatile Express Product Family.

As I have been chastised before, "No, that's a URL. This is a link: http://arm.com/products/tools/development-boards/versatile-express/index.php"

Or more specifically: http://www.arm.com/products/to...

"they won't be designing the same thing 50 times. See that's the ARM markets biggest handicap, there are dozens of companies reinventing the wheel over and over again."

They aren't inventing squat. They're taking a soft IP core processor provided by ARM and connecting their own pieces up to it, same as any other SoC or S-100 computer. No testosterone-drunk manly geek auteur nonsense, just instantiating, wiring, simulating, taping out and profit. Buying that three-year head start from ARM was a good idea for them.

Get yourself a book on Verilog or VHDL and build yourself a couple of toy SoCs using IP from OpenCores. If you're feeling really adventurous, borrow the Hennessey book from someone at work and design your own processor. Really, if you're gonna fanboi, at least know what you're fanboi-ing about.

Instruction set, the set of instructions. ISA, the part of the architecture which handles the instruction set.

Who, other than you, uses that definition of ISA? Intel doesn't, as per my previous post. IBM doesn't, either, and neither does ARM, nor does AMD, nor does Sun^WOracle, for example; they're all using "instruction set architecture" as "instruction set", with "architecture" perhaps given to signify that the instruction set is not just a characteristic of a particular processor, it's something that's specified separately from particular implementations of the instruction set.

Just the decode and encode stages of the CPU

So what does the "encode" stage of a CPU do? Take various internal chip signals and write out instructions to memory?

But originally, the ISA was defined by the very architecture of the processor, and it related directly to the architecture of the underlying processor.

If you mean "in the very early days of computers, the connection between the instruction set and the design of the CPU was straightforward", that might be true, but, dating at least back to the IBM System/360, the same instruction set was implemented by extremely different internal processor designs in many families of computers.

Thumb-2 is a great idea but unfortunately it is not supported for 64 bit mode. 64 bit mode is AArch64 which used 32 bit fixed length instructions

http://www.arm.com/files/downl...

That being said it's not as bad as ARM32

https://groups.google.com/d/to...

So far, the LZSS routine in my code looks like this:
      THUMB2: 76 bytes
      THUMB: 76 bytes
      ARM64: 96 bytes
      ARM32: 116 bytes
(for comparison, x86 is 63 bytes)

Still it is quite a bit worse than x86. x64 incidentally is the same code size as x86

http://www.deater.net/weave/vm...

8086 58 bytes
x86_x32 66 bytes
x86_64 66 bytes
arm_thumb2 76 bytes
arm_thumb 76 bytes
m68k 88 bytes
arm64 96 bytes
z80 96 bytes
arm eabi 116 bytes

Of course this benchmark is a bit silly.

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

There are high end Mali cores - things have moved on in the three years since Mali-400 MP4 was on the market in the Galaxy SII. Sadly it is still a popular GPU core in the low-end market (ARM actually recently created Mali-450 to cater for this area), but there is the Mali T6xx family for higher end uses - e.g., http://www.arm.com/products/multimedia/mali-graphics-plus-gpu-compute/mali-t678.php

Agreed R.e., NVIDIA - Tegra 4 is an outdated GPU core, even by mobile standards, but there's a lot of it to get good performance, and most games don't use the more advanced OpenGL ES 3 yet.

AMD's ARM products aren't out until next year. They'll presumably be an ARM version of their low-end Jaguar-based APUs.

The security of the system is achieved by partitioning all of the SoC hardware and software resources so that they exist in one of two worlds - the Secure world for the security subsystem, and the Normal world for everything else. Hardware logic present in the TrustZone-enabled AMBA3 AXI bus fabric ensures that Normal world components do not access Secure world resources, enabling construction of a strong perimeter boundary between the two. A design that places the sensitive resources in the Secure world, and implements robust software running on the secure processor cores, can protect assets against many possible attacks, including those which are normally difficult to secure, such as passwords entered using a keyboard or touch-screen. By separating security sensitive peripherals through hardware, a designer can limit the number of sub-systems that need to go through security evaluation and therefore save costs when submitting a device for security certification.

http://www.arm.com/products/processors/technologies/trustzone.php?tab=Hardware+Architecture

So yes. ARM enables Apple to physically separate the operation of the biometric device and storage of encrypted biometric information in what Apple calls "secure enclave" storage where it is not available to the OS or to apps.

Nobody did market "cores", as in a small number of parts of a GPU.
Here's one example
Here's another.
Here's another

None of these were before Apple started marketing cores and refer to the same type of "core" that Apple invented.
Anyway, I was talking about phones and tablets. Apple is the first one use use the word "core" while describing its phone GPU when announcing a new phone.

Apple could easily double their CPU performance because they were already 50% slower than the competition.
64 bit is also more power hungry than 32 bit. A 64 bit register uses twice as much power as a 32 bit register. If you use it to make computation on small integers (which is what 99% of applications in the app store do), you use twice the power for no benefit.

Nobody did market "cores", as in a small number of parts of a GPU.
Here's one example
Here's another.
Here's another
Sure seem to be a lot of nobody's around.

What about a fallacy. Just because they doubled the performance doesn't mean that it's because of 64 bit. It's more likely a better architecture and increased clock speed.

It's more likely the whole combination of features. Apple has gotten very good at optimizing performance for mobile devices by cleverly matching the capabilities of their chips to their software. I doubt if going to 64 bit is solely responsible for the increased performance, but I also doubt if it's irrelevant. A doubling of effective performance is a big change for going from one generation to the next of a chip. Apple certainly didn't double clock speed--that would be too expensive in terms of battery usage.

I think that the notion that 64-bit offers little per formance improvement aside from a larger address space comes from people who are more familiar with PCs, which have loads of RAM to play with. But RAM is power-hungry, so cell phones are RAM-constrained. As a result, cell phones are constantly shuffling data back and forth between RAM and Flash memory, and it needs to do this very fast, because users are impatient with lag in a mobile device. And moving data is one place where wider registers yields a big benefit.

Want to add hardware security functions to your ARM design? Here's just one example of how to do it.

http://www.arm.com/community/partners/display_product/rw/ProductId/7255/

Really? Because the ARM white paper seems to indicate otherwise.

http://www.arm.com/files/downloads/big_LITTLE_Final_Final.pdf

"In the big.LITTLE task migration use model the OS and applications only ever execute on Cortex-A15 or Cortex-A7 and never both processors at the same time."

Says it takes about 20 microseconds to switch at 1GHz operating frequency.

It is invoked by setting a power state level and only 4 cores are ever presented to the OS.

There is a type called big.LITTLE MP which presents all 8, but I've found numerous sources(http://arstechnica.com/gadgets/2013/03/samsungs-exynos-5-octa-checking-out-the-chip-inside-the-galaxy-s-4/ to start) saying the S4 does not use this at all. Maybe with a kernel recompile it could be done, but isn't currently.

You are saying that someone who hasn't already had years working on an OSS project will get a paid job with one of those companies.

Yes, yes I am.

I know people who got a job with Arm straight out of an integrated 4 year Engineering Masters degree. Oddly enought for competitive jobs they only hire people who have proven themselves while students.

Pics or it didn't happen.

Well, ARM clearly does hire graduates straight from university, here:

http://www.arm.com/about/careers/graduates/recruitment-events.php

Huh indeed. I think you might be confusing NEON the ARM SIMD engine with OpenMAX the media processing API.

No, you cannot state that using only the article as it is makes no such statement, it only state that he used the source to understand the Secure Monitor Calling convention but I did check in the ARM11 technical reference manual and just as you said it must be in a kernel module as the processor must be in a privileged mode to execute that instruction.

Well the Cortex A15 has both.

Posted Today, 11:40 AM
Hi JimV

Currently the only developer board I am aware of with an OpenCL compatible Mali GPU is the Arndale board. Drivers for this board would have to come from Insignal, but I am not sure what the current status of this support is. The demos themselves will run on desktop however, if you modify the platform.mk in the root directory to use gcc rather than a cross compiler. Provided the necessary libraries are installed on the host machine, the demos will run. The Nexus 10 tablet also contains an OpenCL compatible Mali GPU, however the Android SDK does not currently expose this functionality.

Thanks,
Chris

http://forums.arm.com/index.php?/topic/16523-any-way-to-actually-use-the-mali-opencl-sdk-boards-with-drivers/

In other words, you're still not running CL on mobile devices yet. Have a nice day, and herp a fucking derp.

Yet the SDK is? Unlike the SDK, the driver has obviously been available for some time. Samsung licensing and distributing it is another matter.

So... PCIe daughterboard or thunderbolt peripheral for widespread OpenCL software development using this chip?

ARM have OpenCL drivers, how else could they have submitted the part to Khronos for full profile conformance testing?

Please send your answer over 56kbps dial up via serial port, you may have calmed down by the time we read it. I (for my part) will copy and paste it to a text file on the thunderbolt RAID enclosure under my desk. Also, if you could send some cave paintings...

LMGTFY.

http://www.arm.com/products/processors/licensees.php

I say maybe A15, because from Anandtech's latest review here, Samsung's Exynos 5250 using A15 cores does not have a prayer of getting into smartphones using 5W at load. Your smartphone will be dead in an hour of web browsing with that kind of power draw.

The maximum load is just that, something that the CPU can output when maximum processing is needed, which certainly isn't web browsing. These CPUs scale down both the voltage and frequency when "simple" tasks are needed of them. On top of that, you're going to see a lot of this configuration in phones, too.

ARM has nothing to do with Apple, other than Apple being just one of the many places the licence their CPU designs. Plenty of other companies were doing that before Apple where, and ARM was already very successful before Apple chose to use their designs in things like the iPhone. Still, I guess some people believe that Apple invented everything and that nothing could possible exist without them.

You have no clue, have you (both the AC and the moderator). http://en.wikipedia.org/wiki/ARM_Holdings

The company was founded as Advanced RISC Machines, ARM, a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology. The new company intended to further the development of the Acorn RISC Machine's RISC chip, which was originally used in the Acorn Archimedes and had been selected by Apple for their Newton project.

http://www.arm.com/about/company-profile/milestones.php

Advanced RISC Machines (ARM) spins out of Acorn and Apple Computer's collaboration efforts with a charter to create a new microprocessor standard. VLSI Technology becomes an investor and the first licensee

As a result, there's a whole lot of subtly different variants out there. Not all of them are 100% binary compatible with each other. I haven't been able to find out exactly which variant is used in the raspberry pi.

FTFF, The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with floating point, running at 700Mhz, and a Videocore 4 GPU. (links mine)

When someone buys a design from ARM, they buy one of two things:

1. A Hard macro block. This is like an mspaint version of a cpu. it looks just like the photos here. The CPU has been laid out partially by hand by ARM engineers. The buyer must use it exactly as supplied - changing it would be neigh-on impossible. In the software world, it's the equivalent of giving an exe file.

2. Source Code. This can be compiled by the buyer. Most buyers make minor changes, like adjusting the memory controller or caches, or adding custom FPU-like things. They then compile themselves. Most use a standard compiler rather than hand-laying out the stuff, and performance is therefore lower.

The articles assertion that hand layout hasn't been done for years outside intel as far as I know is codswallop. Elements of hand layout, from gate design to designing memory cells and cache blocks have been present in ARM hard blocks since the very first arm processors. Go look in the lobby at ARM HQ in Cambridge UK and you can see the meticulous hand layout of their first cpu, and it's so simple you can see every wire!

Apple has probably collaborated with ARM to get a hand layout done with apples chosen modifications. I can't see anything new or innovative here.

Evidence: http://www.arm.com/images/A9-osprey-hres.jpg (this is a layout for an ARM Cortex A9)

There are traces of single core cortex A9 on arm's website. But I don't know if there is one FPU or 2 FPUs. But I think there are two.

The scenario here is not a practical one, it is LinPack which is a quite dense computation. Many architecture reaches 90% of peak performance on linpack.

Also you are talking about double precision computation, I am not sure linpack is double precision, it might be single precision. (actually wikipedia confirms it is double precision http://en.wikipedia.org/wiki/LINPACK_benchmarks)

Some of these architectures (not sure about cortex a9) have a separate pipeline for the FPU and the ALU, allowing to perform integer operations and jumping logic in parallel to the floating point operations.

Finally, as you said, cortex A9 can perform one 64 bit FMAC in a cycle. FMAC is fused add multiply, that is to say out = in1 + in2 * in3, so there are 2 Floating point operations performed. ( http://infocenter.arm.com/help/topic/com.arm.doc.dui0068b/Bcfbbjgf.html )

In brief, if there is a single FPU, thanks to fused add multiply, peak performance is 2GFlop/s. If there are 2 FPUs, it is 4GFlop/s.

According to ARM's documentation of the Cortex-A9 FPU it takes two cycles to perform one double-precision FMAC operation. 1 GHz * 2 cores / 2 cycles per operation = 1 GFLOP, assuming ideal conditions and zero overhead. In practical scenarios, 300-400 MFLOP is probably about right. And now that I think about it, the figure they list may already be for a dual-core, since Cortex-A9 was never intended to ship in a single-core configuration.

Jazelle has been gone for years. None of the Cortex series include it. It gave worse performance to a modern JIT, but in a lower memory footprint. It's only useful when you want to run Java apps in 4MB of RAM.

Are you sure? ARM advertises it as part of all architectures from ARMv5 to ARMv8: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf.

i looked in on this project to help earlier this year and found that it's 100% bullshit.

1) the Open Compute Project claims to want energy efficiency but they are using AMD Operon and Intel XEON chips (so inefficient!) instead of something power efficient like ARM chips. why? in case you didnt see, the project is COMPLETELY run by big businesses that have proprietary bullshit that they want to run.

2) they also claim to be making low cost machines. those chips cost >$500 each which is waaaaaay more than any ARM chip. right now you can get quad core ARM chips running at 1.2 GHz and 2.2 GHz in the near future so dont give me that "ARM isnt fast enough!" bullshit.

Open Compute is a fraud

i looked in on this project to help earlier this year and found that it's 100% bullshit.

1) the Open Compute Project claims to want energy efficiency but they are using AMD Operon and Intel XEON chips (so inefficient!) instead of something power efficient like ARM chips. why? in case you didnt see, the project is COMPLETELY run by big businesses that have proprietary bullshit that they want to run.

2) they also claim to be making low cost machines. those chips cost >$500 each which is waaaaaay more than any ARM chip. right now you can get quad core ARM chips running at 1.2 GHz and 2.2 GHz in the near future so dont give me that "ARM isnt fast enough!" bullshit.

Open Compute is a fraud

My personal experience with NEON code cannot really be shared (or even discussed) due to NDA. But I can say that I was surprised how powerful NEON is on those dinky mobile processors....

Why is that? NEON instruction set is open. And as fast as it is, it's no match for a dedicated video decoder chip (both performance-wise and power consumption-wise). It's just a SIMD instruction set, like SSE or 3DNow!, really good for processing several data elements at once, but doesn't offer more parallelism than that.

There are two versions - speed optimised @2ghz and power optimised @800Mhz to ~1GHz. Speed optimised draws 1.9W and power optimised draws 0.5W.

but ARM has 8 (32-bit) general purpose registers, and a few specialized ones, some of which are only available in certain operating modes

That's not correct.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0245a/index.html

2. Register set

The ARM register set consists of 37 general-purpose registers, 16 of which are usable at any one time. The subset which is usable is determined by the current operation mode.

While this is true frankly its only been fairly recently that either AMD or Intel gave a crap about power, and look at how far they've come? Intel has gotten Atoms to less than 3w, AMD has gotten dual cores AND a decent GPU down to 9w in the C Series bobcats, and of course the Intel CULV Core chips can do a scary amount of processing on I believe their latest are sub 10w. Now according to ARM their A9 duals are just a hair under 2w. that of course isn't counting the chips like the hardware decoders typically found with ARM because it just can't do as many IPCs as X86.

So I'd say as folks demand more and more performance out of their mobile devices the advantage will probably swing to Intel.Tthey have the fabs and have been able to shrink quicker than anybody else so 1 or 2 more shrinks and its gonna be pretty damned close and with such a huge IPC difference between X86 and ARM in a damned close race I'm sure many would rather have the faster Intel chip, AMD will most likely be stuck at the niche they are now, at least as long as they stick with the faildozer "half a core" design so that just leaves Intel and ARM and with the money, the fabs, and the R&D budget that Intel has i think it'd be crazy to call it for ARM at this stage of the game.

After all it wasn't too long ago that everyone was making netburst space heater jokes and look how quickly that situation changed. I seriously doubt Intel is gonna sit this one out and when looking at their past record there is no reason to think they can't make a chip that'll compete.

From the summary, which also appears in TFA:

The A5 is the smallest Cortex processor available

Really? I figured that the Cortex-M0 would be smaller. The M0 doesn't even have a cache. Indeed, ARM's Cortex-M0 product page agrees, saying:

The ARM Cortex(tm)-M0 processor is the smallest ARM processor available.

so it's not clear why the article is calling the A5 the smallest?

You kids with your fancy GHz CPU's always forgetting about us small embedded microcontroller guys. Get off my lawn!

Modules intended for DRM purposes are commonly limited to those purposes because running extra code, especially code from random untrusted people, makes your DRM more vulnerable. In this case, AMD seems to be incorporating ARM's "Trustzone" stuff. That does support running vendor-customized software within the 'secure' region; but the suggested implementable does not make that user-modifiable. The rest of it is the usual morass of DRM 'goodies': memory locations 'protected' from access by non 'trusted' software, device unique master key, etc, etc.

That's pretty much why you would have a separate DRM module at all, when you already have a perfectly good x86 core to work with...

It is interesting that AMD appears to be throwing their hat in with this ARM stuff, rather than the 'Trusted Computing Group's TPM, available from a number of vendors on x86s already; but the expected use cases are every bit as malignant...

The A5 is the smallest Cortex processor available

Really? I figured that the Cortex-M0 would be smaller. The M0 doesn't even have a cache. Indeed, ARM's Cortex-M0 product page agrees, saying:

The ARM Cortex(tm)-M0 processor is the smallest ARM processor available.

so it's not clear why the article is calling the A5 the smallest?

http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

ARM devices are very slow compared to x86 ones

I'm not sure where you get this idea. ARM processors may be somewhat slower compared to x86 equivalents at the same clock speed but they make up for it with much better power efficiency and this is how they have a huge advantage in the cloud server space.

they usually do not sport H/W virtualization extensions either

I'm pretty sure ARM has virtualization extensions

ARM devices usually sport quite little memory

My Galaxy S II has 1GB of RAM and a dual-core Cortex-A9 CPU and it came out over 6 months ago. I have never had less than half of that free when not running an app in the foreground.

with all the excess overhead of running x86 applications the battery would see heavy drain

This is entirely speculation on your part. Yes, running a hypervisor and virtualized environment on top of the app's usage would use more processing power (and therefore battery power) than a native equivalent, but would it really necessarily be that much more than running Java bytecode or Flash?

And all of this is ignoring that Windows Phone apps can be written in .NET, which is platform-agnostic, similar to Java, and can therefore run without modification on any platform that supports the API

"No branch prediction" is completely false for modern ARM processors:
http://www.arm.com/products/processors/cortex-a/cortex-a8.php

As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?

Rosetta didn't suck too badly - it ran Quicken 2007 adequately on my MacBook Pro. ("Ran" because I dumped it in favor of Quicken Lite^WEssentials when Q2007 couldn't manage to avoid corrupting one of my credit card accounts.) Unlike the PC emulators, it didn't have to implement the raw hardware - it just had to run usermode code, and it translated system call arguments and results. Dunno how hard it'd be to translate x86 machine code to ARM machine code; if I remember correctly, ARM processors aren't guaranteed to support unaligned accesses, so sufficiently-safe translations of x86 memory-reference instructions might be complicated code sequences. (I'd look it up, but the fine folks at ARM have decided to make their instruction set architecture manuals only "available in [PDF versions] to registered ARM customers". Intel are a bit nicer, as are AMD.)

Huh? Intel's certainly got state of the art manufacturing facilities, but the list of ARM licensees also reads like a "who's who" of the IC manufacturing industry:

http://www.arm.com/products/processors/licensees.php

It's also hard to see Intel wanting to use all their capacity churning out smartphone CPUs that sell for a fraction (1/10?) of the the price of desktop chips. The volume of ARM-based chips that are sold annually is staggering - billions - they are in essentially EVERY consumer electronic device other than desktop/laptop computers.

The Allwinner A10 module still requires a binary blob for the GPU to show accelerated 3d graphics such like the Raspberry Pi. Not that I'm bothered by this. I'm pragmatic first, idealist second. However acting like the A10 is more libre than the the Raspberry Pi is disingenuous. Both will have open source 2d graphics drivers and peripheral drivers. Also I don't see a datasheet for the allwinner A10 anyway at this point just like another project...the raspberry pi. I do see datasheets for the ARM1176JZF-S processor on the Raspberry Pi though. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf

You're talking Windows 7 x64, which is just x86 extended a bit. What I'm talking about is 64 bit Chip, not x86 with 64bit extensions, and all the baggage that comes with it.

If "a 64-bit chip" is a chip with an instruction set that's not derived from an earlier 32-bit instruction set, why do we "need" such a chip? What problems does the "baggage" of 32-bit instruction set support that all x86-64 chips, all 64-bit PowerPC chips, all 64-bit SPARC chips, all 64-bit MIPS chips, all PA-RISC 2.0 chips, and all z/Architecture chips have, and that future ARMv8 chips will have (look for "Allows AArch32 applications under AArch64 OS Kernel" in the ARMv8 presentation), cause that are so severe that we "need a whole class of computers designed and built for 64bit architectures", with "64bit architectures" being those that lack that "baggage" (and thus meaning "IA-64" at this point, unless you know of a plain to resuscitate Alpha)?

And why would that require "a complete redesign" of Windows, rather than a rewrite of the low-level platform support code and a new compiler for the new architecture, given that, for example, Windows did support IA-64, and supported it as a 64-bit architecture (unlike its old support for Alpha with a 32-bit address space and 32-bit pointers)?

I believe the term you're looking for there is "physx", to pull a double entendre and being a pedant at the same time. Graphics performance matters, but I don't really want to sidetrack into that.

It's not the physical limitations of the processors that are at issue for higher performance. It has more to do with "Where can we get more gains"? Performance has been on a continual upward trend, and that hasn't changed. When we get down to 10nm, then we will be facing actual physics issues/limitations *ON SILICON*.There are other technologies in the works here (graphite). Even Intel is exploring this.

It has to do with at it's core, RISC vs CISC. There simply is no way around it until intel actually provides ARM processors. With their attempts to introduce x86 for android, it sounds like they have given up on the ARM route for consumers/entry level, even though they bought a license to ARM.

Unless you're talking about games, there isn't a whole lot this thing won't be able to handle that you'd usually do on an entry level Win7 laptop

An entry level Win7 laptop will run Windows, for starters. Plus it will run a lot faster.

And cost at a bare minimum 15 times as much.

As far as the internet goes, the bottleneck is the pipe, not the computer for the most part. Lightweight applications on this thing will do just fine. And I guess you could have some fun on that front too if you were so inclined: Just how much could you get this thing to do and it still be usable.

And of course, teenagers want to play games, too.

Most teens I know have consoles of some description alongside their PCs. Obviously YMMV on that of course. But then again, whilst this could be put to general purpose use and probably be ok in that role, it's not what it was designed for.

the cpu it's bolted to has plenty of documentation to go with it.

Really? I tried the Broadcom site, and I couldn't find anything. Do you have a link ?

Sure!

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf

Was cited in the Rasberry Pi wiki: http://elinux.org/RaspberryPiBoard

Not surprised you didn't find anything on the Broadcom site though... It's a bit of a pig to navigate around.