Intel Quark SoC running Windows IoT on Intel Galileo (rev 1)

[David Hess]

Pity Intel didn't keep on developing the Alpha chip after they bought it from DEC maybe purchased to settle the lawsuit. Not sure because not a lot of details were made public, or I didn't care enough at the time to find them.

Alpha had its own set of ISA warts so I am not convinced it would have made any difference over the long term.

[Rigby]

I'm not sure what Intel has to do with any of this.  Intel has always made processors, and Intel will always make processors.  The existence of the Quark has little to do with Arduino or anything else other than Intel seeing a market segment, doing some research, and discovering that there is room for something there.  Then, they either buy a company that's already there or they make a new CPU.

Employees don't start off developing i7 processors; they work on the smaller stuff and if they've got the right stuff they move up.  These low-end, low-performance devices are testbeds for employees and for designs.

It's Microsoft that's expanding out into new areas here, not Intel.  Sure, Intel has some new development boards, but they've always had SOME development boards kicking about.  Now they're getting somewhat serious about the low-end (which is new) and Microsoft is supporting that low-end hardware with real, honest-to-goodness operating systems (which is also new.)

The Minnowboard Max and the Sharks Cove boards are kind of where it's going to be for low-end embedded Windows development for the next few months, NOT the Galileo nor the Galileo Gen2 (neither of which make a lot of sense to me.)  The Minnowboard Max especially looks interesting, given the CPU and memory available, and the Sharks Cove will be very interesting to Windows hardware developers who need IO.

[Stonent]

So this is running Windows 6.3.9600 which is Windows 8.1 Update 1 or Server 2012 R2 Update 1.

I recently installed a VM of Microsoft Hyper V 2012 R2 core which boots up like windows but drops you to a powershell prompt when you log in.

At least the Hyper V server uses about 400MB of RAM when it is idle, but it is running some services, this probably is much less, but the fact remains it is windows so there should be a way to install applications on it and get them to display somewhere.

[djacobow]

Intel has always made processors, and Intel will always make processors. 

This is definitely not true. Andy Grove wrote a whole book (Only the Paranoid Survive) about converting Intel from a memory company to a processor company. The fact is, Intel once completely changed its business as a result of getting absolutely creamed in its existing memory business. It was a risky, and spectacularly successful change. Nobody knows if they've got the cajones to do it again, if, say, they realize that high margin desktop processors are becoming an endangered species.

Employees don't start off developing i7 processors; they work on the smaller stuff and if they've got the right stuff they move up. 

Eh, trueish, but there have definitely been times when junior engineers are put on big, major projects, usually with the idea that with guidance and good management they can still make a contribution. I remember one such project: Merced, the first IA64 part. It had hundreds of engineers on it, and many were fresh NCGs. I left shortly after, but perhaps from that fiasco they learned that wasn't such a great idea. However, IMHO, it wasn't junior engineers that sunk that ship, but an inability to manage such a large team along with a few dubious technical decisions (like the way they did x86 compatibility). Personally, I had worked on 1 1/2 "small" projects before my first involvement with a top-line x86 project, though on the latter I was doing pretty menial stuff to start (fault grading).

[Rigby]

The infrastructure required to remote admin or remote desktop into a Galileo isn't present, and we don't have the source to compile it.

The MinnowBoard MAX and Sharks Cove are what you're after if you want full desktop-like stuff.

[Stonent]

The infrastructure required to remote admin or remote desktop into a Galileo isn't present, and we don't have the source to compile it.

The MinnowBoard MAX and Sharks Cove are what you're after if you want full desktop-like stuff.

It should all be about just modifying the registry and including the missing files.

[Rigby]

It should all be about just modifying the registry and including the missing files.

If the Quark had all the CPU features that the binaries you copy over require, I would agree.  Alas, the Quark doesn't have a lot of things that have been standard in desktop & laptop CPUs for over a decade.  The Quark has no SIMD (MMX, SSE, etc.) instructions at all, and I doubt you'll find any modern Windows core stuff compiled without the need for those.

I would love to be proven wrong on this.

[David Hess]

The Quark has no SIMD (MMX, SSE, etc.) instructions at all, and I doubt you'll find any modern Windows core stuff compiled without the need for those.

I have run across an increasing number of applications and libraries which test for and require instruction extensions that they do not need so they cannot be used on older (but not that much older) Intel processors.

[Rory]

Waiting for mine to show up, I'd like to try adapting some Powerbasic apps to the Quark.

[Rigby]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

[coppice]

Intel has always made processors, and Intel will always make processors. 

This is definitely not true. Andy Grove wrote a whole book (Only the Paranoid Survive) about converting Intel from a memory company to a processor company. The fact is, Intel once completely changed its business as a result of getting absolutely creamed in its existing memory business. It was a risky, and spectacularly successful change. Nobody knows if they've got the cajones to do it again, if, say, they realize that high margin desktop processors are becoming an endangered species.

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers. 

[David Hess]

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

One of Grove's points in his book that it was not luck.  They saw what was going to happen in the memory market and made a deliberate choice to move while they were strong without knowing where they were going.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers.

There would not have been an 8086 PC business to drift except they agreed to license second sources at IBM's insistence.

[coppice]

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

One of Grove's points in his book that it was not luck.  They saw what was going to happen in the memory market and made a deliberate choice to move while they were strong without knowing where they were going.

Andy Grove saw that they were going to screw up DRAM technology, and produce junk nobody wanted, while the Japanese would invest in solving the problems and whip their asses? Interesting admission. The fact that many industry watchers where expecting them to go bankrupt doesn't really support the idea that their survival was not mostly luck.

Its interesting how history gets revised in such a short period. If you look up the 64k and 256k DRAM generations on the web you will find lots of stuff about the Japanese winning by dumping below cost. I remember when people like HP declared they would only use Japanese DRAM, as the American stuff prevented them offering meaningful SLAs to their computer customers. Cost is always an important factor, but it was reliability issues that let the Japanese win that time around.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers.

There would not have been an 8086 PC business to drift except they agreed to license second sources at IBM's insistence.

In those days you *had* to have second sources, or people wouldn't design your parts into anything strategic. Motorola and Intel both courted second sources for that reason. Intel also needed access to someone's CMOS processes, too. Motorola only needed second sources.

[miguelvp]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

I thought MMX and SSE were oriented for video and 3d, maybe some dsp can get gains from it too but not a show stopper.

[coppice]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

I thought MMX and SSE were oriented for video and 3d, maybe some dsp can get gains from it too but not a show stopper.

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

[David Hess]

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

You should read one of the rants from Linus Torvalds on the subject of optimizations and SSE versus REP MOVSB memory copies.

[coppice]

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

You should read one of the rants from Linus Torvalds on the subject of optimizations and SSE versus REP MOVSB memory copies.

I know about that. The x86 processors of the last 2 or 3 years have finally made REP MOVSB perform well, but it used to perform really badly, and lead to the implementation of SSE based copying. I expect the standard memcpy will move back from SSE to a simple rep movsb, but the software is always waaaaaay behind the hardware.