Linked by Thom Holwerda on Thu 28th Jan 2010 20:21 UTC
Hardware, Embedded Systems And yet another item on the iPad? Are we serious? Yes, we are, since this one is about something that even geeks who aren't interested in the iPad itself should find intriguing. Steve Jobs said yesterday that the iPad is powered by an Apple A4 processor, but contrary to what many seem to think - it wasn't designed in-house at all.
Thread beginning with comment 406634
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: ARM
by lemur2 on Fri 29th Jan 2010 12:34 UTC in reply to "RE[2]: ARM"
lemur2
Member since:
2007-02-17

Not necessarily. Remember Transmeta Crusoe?
An ARM is a RISC chip. x86 is CISC, or more accurately these days (Core architecture) a RISC chip with CISC macros. Somebody could create a hardware x86 translater to convert the CISC commands to the RISC commands. Transmeta did the same thing, but in software, that was why it was slow--but the principle was sound. x86 would not be difficult to emulate, you just have to get over the behemoth that is Intel and give people a reason why they'd want x86 compatibility as a secondary function.


A similar type of thing is actually embedded in the Loongson CPU, isn't it?

http://en.wikipedia.org/wiki/Dragon_chip
http://en.wikipedia.org/wiki/Dragon_chip#Hardware-assisted_x86_emul...
Loongson 3 adds over 200 new instructions to speed up x86 instruction execution at a cost of 5% of the total die area. The new instructions help QEMU translate x86 instructions by lowering the overhead of executing x86/CISC-style instructions in the MIPS pipeline. With additional improvements in QEMU from ICT, Loongson-3 achieves an average of 70% the performance of executing native binaries while running x86 binaries from nine benchmarks.


Even with 200 extra specialist macro-instructions (hardly RISC-like any more, and coming at a cost of 5% extra die area), Loongson-3 achieves only 70% the native performance when emulating x86.

Without all that extra help embedded in the CPU die, ARM would get nowhere near that. It would be a dog performance-wise when trying to run (emulate) x86 binaries.

Exactly why would anyone want to run x86 binary executables non-natively on ARM at dog-slow performance when there are 20,000+ native ARM packages (which would all work at full CPU performance) for malware-free, zero-cost, full-driver-and-peripheral-support Linux, which cover every conceivable use case for a tablet or a netbook class ARM machine?

Edited 2010-01-29 12:41 UTC

Reply Parent Score: 2

RE[4]: ARM
by tylerdurden on Fri 29th Jan 2010 23:21 in reply to "RE[3]: ARM"
tylerdurden Member since:
2009-03-17

A lot of people do not seem to understand that the "reduced" in RISC refers to the cycles per instruction, not the number of instructions.

Some of the early RISC designs included more instructions in their ISA than their CISC counterparts.

Reply Parent Score: 1

RE[5]: ARM
by lemur2 on Sat 30th Jan 2010 14:01 in reply to "RE[4]: ARM"
lemur2 Member since:
2007-02-17

A lot of people do not seem to understand that the "reduced" in RISC refers to the cycles per instruction, not the number of instructions.

Some of the early RISC designs included more instructions in their ISA than their CISC counterparts.


This has nothing to do with the point made in the post to which you responded.

The Loongson CPU includes a lot of support in terms of extra macro-instructions in order to assist with x86 emulation, and still it achieves only 70% of native performance.

ARM does not include any such support at all, so x86 must be entirely emulated in software.

Hence, the performance of a low-power ARM chip running x86 binaries under emulation will be dismal. Hence, copies of x86 binary executable applications will be utterly useless the Windows on ARM.

Hence, Windows on ARM will not have the benefit of the existing corpus of x86 Windows applications.

That was the point.

Reply Parent Score: 2

RE[5]: ARM
by torbenm on Mon 1st Feb 2010 11:16 in reply to "RE[4]: ARM"
torbenm Member since:
2007-04-23

A lot of people do not seem to understand that the "reduced" in RISC refers to the cycles per instruction, not the number of instructions.

Some of the early RISC designs included more instructions in their ISA than their CISC counterparts.


Counting the number of different instructions on a CPU is not so easy as it sounds. For example:

CPU A has an ADD instruction, and ADC (add with carry) instruction, ADDI and ADCI (immediate versions of the above) and several shift/rotate instructions.

CPU B has a single ADD instruction with a modification bit that specifies whether the carry flag is used and a bit that specifies if the next 12 bits is read as an immediate constant or as a register that can optionally be shifted or rotated.

So which CPU has more instruction? You could choose to read every combination of bits that do not specify registers or constants as separate instructions or treat all the combinations as a single parameterised instruction. So you very quickly end up comparing apples to oranges when you try to count instructions.

RISC is usually read as meaning "reduced complexity instruction set". This often implied lower cycle count per instructions, but it was not lowering cycle count that was the main motivation, it was providing the most performance given a limited transistor budget. In comparison, 80386 (1985) used 275000 transistors while ARM1 (1985) used 24000 transistors and ARM2 (1987) used 25000 transistors. Granted, the 80386 had address translation on chip, but so did the later ARM600 which used 33500 transistors.

In any case, given the transistor budgets these days, the RISC vs. CISC distinction is getting increasingly muddied, and the challenge these days is not so much getting the most performance for a given transistor budget (as transistors are cheap), but rather for a given power budget. These are not entirely unrelated, though.

Reply Parent Score: 1