Intel's new microcontroller

[kfitch42]

Normally ISA doesn't matter very much in a microcontroller, in large part because most of the microcontrollers these days have converged on similar behaviour for their ISAs. On the other hand, x86 is actually a poor choice for a microcontroller. When reaching for a micro you are usually in a problem space that worries about latency more than throughput. The complexity of x86 makes predictable latency hard (but not entirely impossible). I see two problems with x86:
1) Variable length instructions: In a desktop (throughput dominated) problem space this is actually a (small) win since you can have better code density which means better usage of L1 code cache space. In an embedded problem space (latency dominated) this can add weird hiccups to the code execution. Sometimes an memory fetch gets multiple instructions, sometimes it takes multiple fetches to get 1 instruction...
2) More complex pipeline: In order to really execute x86 code you need the CPU to translate it needs to be "cracked" into more RISC like internal instructions. This is again a win for Desktop situations where the the same compiled code can run across multiple generations of CPUs that look VERY differently internally, but still take the same x86 code as input. On a power limited microcontroller this is a problem. The translation logic doesn't scale down when you scale down the rest of the CPU. So, it takes a bigger portion of the overall die space and power on a smaller CPU.

[andersm]

1) Variable length instructions

Funny that you think it's a problem, because few architectures actually use fixed-length instructions. Even classic RISC-style architectures have added or moved to variable-length to increase code density (eg. Thumb-2, microMIPS, Power VLE).

2) More complex pipeline: In order to really execute x86 code you need the CPU to translate it needs to be "cracked" into more RISC like internal instructions.

The Quark is basically an i486, and has a single-issue, in-order, 5-stage pipeline. Instruction cracking and the likes didn't appear until much later. AFAIK, x86 was (and still is) a fairly popular industrial real-time platform, and several RTOSes (eg. µC/OS, RTXC) were first written for that architecture.

[neil555]

Hmmmm, looks interesting *BUT*

It's too slow (even the STM8/AVR etc is almost as fast)
8K of ram is pathetically small
QFN's are a bitch to solder especially for hobbyists making their own boards

If it was available in LQFP, ran at like 100Mhz and had 64K (or more) ram then i could think of loads of uses for it, eeh well 

[free_electron]

Hell I didn't even know Intel made microcontrollers.

they invented them ... the 4040 ( not the 4004 ) was the first microcontroller they made. followed by 8048 and 8051 and 8096

[free_electron]

Hell I didn't even know Intel made microcontrollers.

they invented them ... the 4040 ( not the 4004 ) was the first microcontroller they made. followed by 8048 and 8051 and 8096

I'm sure at one point I was told that,but I've never seen or heard of any of their uc offereings until now. I see DK stocks some of their uc's, not much though , Newark has none.

Hmm, learn something new everyday.

They pulled out of the microcontroller market long before most companies even entered that market ...

[coppice]

Hell I didn't even know Intel made microcontrollers.

they invented them ... the 4040 ( not the 4004 ) was the first microcontroller they made. followed by 8048 and 8051 and 8096

The 4004 and 4040 were not microcontrollers. They were microprocessors. The 4004 was not actually the first microprocessors, but it was the first to achieve any significant sales. The first microcontroller was probably the TI TMS1000, which was a 4 bit device and sold in really big numbers. TI had a big advertising campaign when it hit 100 million units, which was a vast number for a chip in those days. Intel probably made the first 8 bit microcontroller, the 8048.

[rsjsouza]

1) Variable length instructions

Funny that you think it's a problem, because few architectures actually use fixed-length instructions. Even classic RISC-style architectures have added or moved to variable-length to increase code density (eg. Thumb-2, microMIPS, Power VLE).

+1 to that. In addition to the examples above, several DSP architectures have variable length execution and they are very demanding in terms of latency and predictive code. One detail that makes it harder on embedded systems is out-of-order execution, which was starting to make inroads in 486 processors (although only fully implemented in Pentiums).

2) More complex pipeline: In order to really execute x86 code you need the CPU to translate it needs to be "cracked" into more RISC like internal instructions.

The Quark is basically an i486, and has a single-issue, in-order, 5-stage pipeline. Instruction cracking and the likes didn't appear until much later. AFAIK, x86 was (and still is) a fairly popular industrial real-time platform, and several RTOSes (eg. µC/OS, RTXC) were first written for that architecture.

Similarly as before: DSPs also have long pipelines which do not translate into loss of predictive behaviour. Also, ARM mentions Thumb ISA is translated internally into ARM microcode.

The 4004 and 4040 were not microcontrollers. They were microprocessors. The 4004 was not actually the first microprocessors, but it was the first to achieve any significant sales. The first microcontroller was probably the TI TMS1000, which was a 4 bit device and sold in really big numbers. TI had a big advertising campaign when it hit 100 million units, which was a vast number for a chip in those days. Intel probably made the first 8 bit microcontroller, the 8048.

Although it is generally believed Intel invented the microprocessor and TI the microcontroller, the history is somewhat controversial as to "who made what first", when TI was granted with a patent for the TMS1000 as the first microprocessor and Intel paying royalties to them.

Back in the 90's I was already working with PC-104 architecture for industrial control - a big honking 486 running at a decent speed for its time (33MHz). If these processors can run DOS (I wish!) or a decent RTOS, it is a good headstart. However, everything relies on the availability of a decent BSP (Board Support Package).

All in all, I always believed that, when the largest semiconductor manufacturer on the planet makes a move we better be on the lookout.

[commie]

I can't understand peoples interest in 32 bit mcu's mainly because you dont get any bang for buck which is governed by the supporting compiler. For example, I would expect a 32 bitter to do one 32-bit flop per clk cycle. The way things look, they don't even support 64 bit floats.The supporting 32-bit compilers are deliberately impeded so whats the point? 

Well, the electronics industry has got about 25years worth of technology still to feed through to us and they are certainly dragging their feet about giving it to us and that's with a technology that's ever speeding up with the time.

Another thing, prototyping would be very difficult due to the packages these 32-bitters come in, making the only choice being a 3rd party or vender evaluation kit or breakout board. Nah, not interested, I'm sticking with 8 bitters for now.

[mikerj]

I can't understand peoples interest in 32 bit mcu's mainly because you dont get any bang for buck which is governed by the supporting compiler. For example, I would expect a 32 bitter to do one 32-bit flop per clk cycle.

Why would you expect that if a micro doesn't have an FPU?

The way things look, they don't even support 64 bit floats.The supporting 32-bit compilers are deliberately impeded so whats the point? 

How often do you really need to use single cycle double precision floats on a general purpose microcontroller?  If you are after serious number crunching then you;d be using a DSP.

In what way are 32 bits compilers "deliberately impeded"?  Are you drawing assumptions based on a single compiler vendor?

[rolycat]

Hell I didn't even know Intel made microcontrollers.

they invented them ... the 4040 ( not the 4004 ) was the first microcontroller they made. followed by 8048 and 8051 and 8096

My understanding is that Texas Instruments invented the microcontroller, not Intel.

The Intel 4040 - like its predecessor the 4004 - had no I/O and no onboard memory.
TI launched a single-chip microcontroller configured as a dedicated calculator chip in 1972, and a general purpose version (the TMS1000) in 1974, the same year as Intel's 4040 microprocessor.

Intel's first microcontroller (the MCS-48 series which included the 8048) wasn't released until 1976.

It could be argued that TI also invented the microprocessor. There seems to be evidence that although the 4004 was the first commercially available microprocessor, Intel were already paying royalties to TI for their microprocessor patent when the 4004 was launched in 1971.

[bson]

There's still a substantial x86 legacy embedded market.  This looks like the IA32 version of the EM188Ex series from AMD 20 years ago.  Probably a hit in that market.  Without getting too abrasive about it, any engineer who uses IA32 for new designs though really needs to get out more.

[helius]

It could be argued that TI also invented the microprocessor. There seems to be evidence that although the 4004 was the first commercially available microprocessor, Intel were already paying royalties to TI for their microprocessor patent when the 4004 was launched in 1971.

The MP944 microprocessor used in the F-14A aircraft was completed before that, in 1970. In a replay of the events that led to the ENIAC and not the Colossus getting credit for the first electronic computer, the paper describing the MP944 was classified and not widely known.
https://en.wikipedia.org/wiki/Central_Air_Data_Computer

[commie]

Why would you expect that if a micro doesn't have an FPU? 

Well, if you are using a 32 bit micro then it should do 32 bit flops every cycle otherwise I might as well carry on with 8 bit micro's

How often do you really need to use single cycle double precision floats on a general purpose microcontroller?  If you are after serious number crunching then you;d be using a DSP.

In what way are 32 bits compilers "deliberately impeded"?  Are you drawing assumptions based on a single compiler vendor?

All of the time, it's nice to have at your disposal, my AVR 8-bit compiler has 64-bit floats, the AVR ATMEGA are hardly dsp. Perhaps you can name a compiler for a 32 bit micro that supports double floats?
The specific compiler in use unlocks the power of your micro not the other way about.

[coppice]

It could be argued that TI also invented the microprocessor. There seems to be evidence that although the 4004 was the first commercially available microprocessor, Intel were already paying royalties to TI for their microprocessor patent when the 4004 was launched in 1971.

The MP944 microprocessor used in the F-14A aircraft was completed before that, in 1970. In a replay of the events that led to the ENIAC and not the Colossus getting credit for the first electronic computer, the paper describing the MP944 was classified and not widely known.
https://en.wikipedia.org/wiki/Central_Air_Data_Computer

There were other early single chip processor activities too. People still question who developed the first single chip CPU, but there is no doubt that it wasn't Intel or TI.

[Kalvin]

Why would you expect that if a micro doesn't have an FPU? 

Well, if you are using a 32 bit micro then it should do 32 bit flops every cycle otherwise I might as well carry on with 8 bit micro's

Your opinion might be very biased as your are only after 64-bit FPU, and you fail to see other benefits of using 32-bit MCUs over 8-bit MCUs.

A 32-bit MCU can typically perform one instruction per clock cycle, where the older 8-bit architectures spend two to four cycles. However, the modern 8-bit architectures will perform one instruction per clock cycle, too. But the performance is more than just instructions per clock cycle, so please read on.

Quite often though the needed data types are either 16 bit or 32 bit signed and unsigned integers. The 32-bit architecture can process the operation in few instruction cycles (fetch operands, operand, write the result back. But if the operands are already in the registers, then the operation can be performed in a single clock cycle). The 8-bit MCU need quite many instruction cycles to perform the 16-bit and 32-bit operations.

Also the memory access using pointers etc. is much efficient using 32-bit architecture than 8-bit architecture.

Code density will be better on 32-bit architecture. The compilers will typically be able to generate more efficient code for the 32-bit architectures than 8-bit architectures are there are typically more registers available to store intermediate results.

There is a speed benefit using 32-bit architecture as fewer instruction cycles are needed to perform the algorithm, so they are more suitable in high demanding, embedded real-time applications.

8-bit MCUs may still have a energy consumption advantage, but the 32-bit architectures are catching up.

[coppice]

8-bit MCUs may still have a energy consumption advantage, but the 32-bit architectures are catching up.

Its a long time since an 8 bit MCU was the lowest energy consuming MCU on the market.

[westfw]

Speaking of... MSP430 also has a (very) variable length instruction (and direct memory operations), rather like x86.

[mikerj]

Why would you expect that if a micro doesn't have an FPU? 

Well, if you are using a 32 bit micro then it should do 32 bit flops every cycle otherwise I might as well carry on with 8 bit micro's

What a ridiculous statement   How many cycles does it take to perform a floating point operation on your 8 bit micro?

If neither the 32 bit micro or the 8 bit micro have an FPU, then the 32bit device is going to be significantly faster doing floating point calculations through software.  The 32 bit device is also going to be significantly faster whenever you are dealing with integer values larger than 8 bits.

If you do want an FPU then your choice of 8 bit devices is going to be close to zero (are there any at all?), but there are numerous 32 bit devices that include this function.

How often do you really need to use single cycle double precision floats on a general purpose microcontroller?  If you are after serious number crunching then you;d be using a DSP.

In what way are 32 bits compilers "deliberately impeded"?  Are you drawing assumptions based on a single compiler vendor?

All of the time, it's nice to have at your disposal, my AVR 8-bit compiler has 64-bit floats, the AVR ATMEGA are hardly dsp. Perhaps you can name a compiler for a 32 bit micro that supports double floats?
The specific compiler in use unlocks the power of your micro not the other way about.

The majority of compilers for 32 bit devices support double precision floats.  The one I frequently use (Keil MDK-ARM) does, and as far as I know the GCC compiler does as well.  Again, it seems like you have maybe had a bad experience with one compiler and you've extrapolated this to all other compilers.

Even if you had a compiler that didn't include support for doubles, then there is nothing stopping you using a third party library or making your own.  It's hardly rocket science.

[commie]

The majority of compilers for 32 bit devices support double precision floats.  The one I frequently use (Keil MDK-ARM) does,

Here's the price of your ARM compiler,      http://uk.farnell.com/arm/mdk-arm/software-mdk-std-std-node-locked/dp/2309940

and that's ex-vat, had a quick wiz through it's data sheet, gives no information whether it has 64-bit float support or not.

Heck Mike, what are you designing F14-Tomcat flight control systems?

[c4757p]

Which AVR compiler are you using that has 64-bit floats? avr-gcc fakes them...

[commie]

Which AVR compiler are you using that has 64-bit floats? avr-gcc fakes them...

http://www.mcselec.com/

I also believe, although not sure that Imagecraft pro supports 64-bit floats. For those that don't know it, 64 bit floats produce 15 digits of precision.

[mikerj]

Heck Mike, what are you designing F14-Tomcat flight control systems?

Not quite (though we used to make a part for the Eurofighter Typhoon IIRC), but it's pretty much the industry standard C compiler for ARM devices (since they use the official ARM compiler).  I agree that the full version it's too expensive for a hobbyist or most small businesses, but the lite version is still very capable.

Until you start seriously using 32 bit micros you won't know just how much performance advantage they have over the old 8 bit parts.  We've used PIC, AVR and H8 micros in various products over the years and they were fine at the time but we wouldn't consider going back to them now.  Not only do they represent poor value in terms of performance/$, once you start needing larger amounts of memory and I/O then 8 bit parts just don't cut the mustard.

[westfw]

If neither the 32 bit micro or the 8 bit micro have an FPU, then the 32bit device is going to be significantly faster doing floating point calculations through software.

Unfortunately, this isn't necessarily true.  Float support in gcc will "default" to the GNU SW floating point support, which is written entirely in C, and is neither fast nor small.  While an 8-bit micro with float support PROBABLY has optimized assembler.   Various people in Arduino-land have been shocked when their floating-point intensive sketches do not get "much faster" when run on the ARM boards.  (here's one thread: http://forum.arduino.cc/index.php?topic=138802.0 Arduino Due, about 3.5x faster than Arduino MEGA, despite 32bits and 5x clock.)  Part of that is that their "doubles" (and FP constants) suddenly go from 32bits to 64bits, and their trig functions like "sin" all operate on doubles (and have an extra conversion step if they HAD used "float", but a lot of it is that the AVR floating point math library is ... really good, while the ARM floating point library ... isn't.
Looking at the arm-gcc source, I see that there are assembler functions for basic float/double math (.../src/gcc/libgcc/config/arm/ieee754*.S), but no optimized higher-level functions (trig/etc.)  Except that they're ARM32/THUMB2 instructions, and don't work on CM0 (so CM0 takes the added hit of going back to the C code.)  Meh.

Perhaps you can name a compiler for a 32 bit micro that supports double floats?

gcc for ARM, as described above.  PIC32 as well.  Probably MOST gcc targets, though not "well."  I haven't figured out whether it's able to leverage 32bit float hardware (ie on CM4F) when doing 64bit float math...

[helius]

Part of that is that their "doubles" (and FP constants) suddenly go from 32bits to 64bits

IEEE 754 double-precision is defined as 64-bits. Some of the other slowness could be "more ambitious" soft float implementations that try to follow more of the standard, which is quite specific about what happens in every situation.

[richardman]

I also believe, although not sure that Imagecraft pro supports 64-bit floats. For those that don't know it, 64 bit floats produce 15 digits of precision.

Yes we do. Although we still have a user option to select 32/64 bit "double". 64-bits FP is dog-slow with the AVR, there's just no two way about it. Probably a well written set of asm routines will be 3x faster, but you will be starting from the state of molasses, so ...