Intel powers an Arduino
Intel powers an Arduino
Posted Oct 4, 2013 21:16 UTC (Fri) by drag (guest, #31333)In reply to: Intel powers an Arduino by khim
Parent article: Intel powers an Arduino for the first time with new “Galileo” board (ars technica)
Posted Oct 6, 2013 2:40 UTC (Sun)
by oshepherd (guest, #90163)
[Link] (16 responses)
The processor in this thing runs x86 code. That's, you know, a prerequisite of being an x86...
Posted Oct 6, 2013 7:45 UTC (Sun)
by drag (guest, #31333)
[Link] (15 responses)
Intel (and AMD) processors are actually RISC. They have not produced a true CISC processor since the Pentium 2 I think.
What they do have, however, is a hardware translation layer that dynamically translates x86/x86_64 machine code to another machine code format that is actually executed on the core processors.
The x86 or x86_64 is the 'ISA', a standard language interface of sorts. Another way to think about it is that you really have a x86 'virtual machine', but instead of doing the processor emulation in software Intel does it in hardware.
This is a very complex thing to do in hardware and maintain good performance. Normally this is not a big deal because the logic required to do the translation was much smaller then the rest of the processor, however as Intel tries to simplify their processors and scale them down they can't get away from the huge ISA translation layer.
ARM, on the other hand, comes out with new architectures on a regular basis. They don't mind breaking their machine language compatibility and will add and changes things as they see fit.
This reflects the different goals and successes of the original architectures.
This one of the major reasons why ARM has, so far, been ahead of Intel in terms of performance per watt even though people that license their processor designs have cpu manufacturing processes tend to be a few years behind.
Posted Oct 6, 2013 10:56 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
Apparently it's still true for AMD, but no longer true for Intel. I'm not 100% convinced that it's just a shrink of P54C but something like this highly likely: this will explain all observable quite well: that's how you can make it five times smaller and ten times more energy-efficient then Atom, etc. Five times smaller means that it has about the same number of transistors as Pentium !!! core and there are a lot of other things besides core!
Posted Oct 6, 2013 12:31 UTC (Sun)
by pboddie (guest, #50784)
[Link]
I'm sure you can dig something up about this, but I'm also sure that various AMD product lines went through a transition to RISC (or started out life as RISC) with some kind of x86 translation being used to satisfy the needs of everyone who can't manage to recompile their software. See this page on the Nx586 with a note about RISC86 instructions, for instance. Of course, AMD have acquired technologies that should have allowed them to put desktop-class products into low power devices. The Geode CPUs (which will supposedly be discontinued fairly soon) are an example of this, although they apparently use traditional microcode implementing x86 instructions directly. Maybe AMD didn't see any future for this approach either in terms of power or performance, effectively bringing to an end a product line that in fact originally came from another x86 competitor, Cyrix. The NexGen approach was the one that worked best for AMD, I guess.
Posted Oct 6, 2013 17:03 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (6 responses)
In SoCs like Quark, the *entire* CPU core is small compared to the rest of the SoC anyway.
I suspect power is a different question than you think it is.
Posted Oct 6, 2013 17:39 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
That's true for most SoCs, but I doubt it's true for Quark. Quark is billed as ⅕ of Atom. Atom has about 50 million transistors thus Quark should have about 10 million. If you'll recall that even original Pentium had 3.1 million and also consider the fact that Quark is supposed to be synthesizable we should expect between 3 and 5 million transistors just for that single core. That's hardly small compared to the rest of the SoC anyway. P.S. Of course Intel could have used 80486 core which only had ~1.2 million transistors but in that case it's 400MHz will deliver pretty pitiful performance by today's standards thus I hope it's at least Pentium-class CPU. And even in that case it'll be ⅒ of the whole SoC!
Posted Oct 7, 2013 5:36 UTC (Mon)
by nhippi (subscriber, #34640)
[Link] (2 responses)
This is the first rasberry pi killer that is actually slower than rasberry pi.
Posted Oct 7, 2013 6:31 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 8, 2013 5:53 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Posted Oct 7, 2013 13:57 UTC (Mon)
by drag (guest, #31333)
[Link] (1 responses)
I don't understand how that matters to what I said.
They obviously do the SoC thing because it's cheaper to produce computers were everything is in one big integrated circuit and it's more power efficient. It significantly reduces cost of the device because you can significantly reduce the complexity of the mainboard and such things. All the little chips and power converters you would need otherwise adds up considerably.
But that doesn't nullify or contradict the fact that x86 ISA causes significant overhead for the CPU that ARM doesn't have to deal with.
Posted Oct 7, 2013 21:14 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
It does not nullify or contradict it (another discussion); it makes it irrelevant.
Posted Oct 7, 2013 9:13 UTC (Mon)
by renox (guest, #23785)
[Link] (3 responses)
Oh, they ditched the x86 ISA, now they have a reduced INSTRUCTION SET cpu(computer)?
You can't so the external instruction set is still CISC, whether it is implemented internally using a RISC or not doesn't change the external instruction set accessible.
Posted Oct 7, 2013 13:52 UTC (Mon)
by drag (guest, #31333)
[Link] (2 responses)
They didn't?
> Tell me how you or your compiler can access directly these RISC instructions?
It doesn't.
> You can't so the external instruction set is still CISC, whether it is implemented internally using a RISC or not doesn't change the external instruction set accessible.
Irrelevant to what I was talking about.
Posted Oct 7, 2013 14:26 UTC (Mon)
by renox (guest, #23785)
[Link] (1 responses)
And? You still wrote an incorrect assertion..
Posted Oct 7, 2013 15:44 UTC (Mon)
by pboddie (guest, #50784)
[Link]
Posted Oct 7, 2013 11:04 UTC (Mon)
by k8to (guest, #15413)
[Link]
None of that has to do with the size of the instructions as stored in memory or flash, though. In fact all the higher performing comptemporary designs (mips, sparc, power(pc), etc) all had *larger* memory footprints for the same program compiled to their instruction streams. They eschewed complexity in instructions in order to have simpler decode, and many things took multiple instructions that in x86 could be done in one. The most obvious example (though not the most significant in overall size) was the way that function calls were typically encoded.
Of the popular arches around that time, only the 68k instruction set tended to be a bit smaller than x86, but that's certainly not RISC-like at all, only less baroque.
There were some very compact instruction sets emerging a bit later in the 32bit space (like 1997ish?), notably Arm "thumb", which was a 16-bit packed conceptually 32bit instruction stream. It certainly saved a bunch of space, but the much *more* complex decode logic limited the performance too much for most users.
However, in the deeply embedded space, where 32bit flat memory models weren't valued, there were a variety of instruction sets more optimized for size. This was both for a desire to may very inexpensive CPUs but more significantly to make inexpensive total parts, including storage and cpu. I'm not an expert on these arches, but that's the heritage of Arduino, PIC, etc. It's not that they're "risc" or "simple", it's that the designers wanted to run programs out of tiny flash spaces or on-cpu memory.
But even this isn't really enough to explain the difference between sizes like 32kb and 8MB. Either the 8MB rom has a lot of functionality the 32kb doesn't, or it's meant as user-burn space to run out of rom, or it's written by jokers. Any are possible. A lot of 32bit development boards in the 90s came with completely jokey roms that you immediately erased and replaced with something reasonable. I left that world around 2000, so I couldn't say now.
Posted Oct 8, 2013 7:48 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Intel powers an Arduino
Intel powers an Arduino
Intel powers an Arduino
Intel (and AMD) processors are actually RISC. They have not produced a true CISC processor since the Pentium 2 I think.
Intel powers an Arduino
Intel powers an Arduino
Intel powers an Arduino
In SoCs like Quark, the *entire* CPU core is small compared to the rest of the SoC anyway.
Intel powers an Arduino
Intel powers an Arduino
Probably. But they are not doing that: this thing is only clocked @ 400MHz. If it's Pentium then 400MHz is in “not superfast, but faster than many others” ballpack, if it's 80486 then it's in “WTF?” ballpack. Adruino says it's 400MHz 32-bit Intel® Pentium instruction set architecture (ISA)-compatible processor o 16 KBytes on-die L1 cache which does not say us much: 80846 and Pentium has very little difference from is ISA POV and later models of both had 16 KByte cache thus 80486 looks plausible, too.
Intel powers an Arduino
Intel powers an Arduino
Intel powers an Arduino
Intel powers an Arduino
Tell me how you or your compiler can access directly these RISC instructions?
Intel powers an Arduino
Intel powers an Arduino
*Using* internally a RISC or *being* a RISC i.e having an externally accessible ISA which is "reduced" are different things, whether it is relevant to your discussion or not I don't care.
Intel powers an Arduino
Intel powers an Arduino
Intel powers an Arduino