Hacker News new | comments | show | ask | jobs | submit login
Intel Quark Runs on Roof, Raises Questions (eetimes.com)
24 points by ChuckMcM 1079 days ago | hide | past | web | 22 comments | favorite

"We looked at Freescale and ARM too but decided on using Quark"

Interesting that he doesn't say why here. There's no "it simply had better performance", "it did more with the power budget" or other reason.

I suspect Intel were quite eager to have a customer and case study to launch with.

That's the part that doesn't click with me.

This customer designs industrial HVAC systems, which suck hundreds if not thousands of kilowatt-hours per day. Millions of watts. And they're excited that the Quark draws a few milliwatts less than a competitor's part? Or that it saves a few dollars in the $100,000 bill of materials?

A better case study would someone doing a wireless sensor working off a battery in a cornfield or something. Show us the performance per watt.

Two sentences later: "Security software gave Intel the edge over ARM."

It's a pretty lame reason. A "HVAC giant" should easily be able to lean on a software vendor to get their software running on anything (sane) they ask them to.

(McAfee security software? really?)

>(McAfee security software? really?)

It's a name people who wear hard hats recognize. Commercial HVAC people aren't hip like us.

It's also an Intel subsidiary.

If it's that critical they could opt for a tailored solution. They want an off the shelf combo deal attached to big names.

I agree. The only distiction mentioned is Wind River (owned by Intel) and MacAfee security. There's nothing singular about that whole package beyond branding.

McAfee is also owned by Intel.

So if you were still wondering if ARM isn't directly lined up in Intel's sights, this should dispel that notion.

For a couple of years now I've noted that one advantage ARM had that seemed quite durable was you could put it into the SOC of your own design, but you could not do that with an x86 chip. If Intel is willing to allow that it is a potent weapon.

Can someone knowledgeable comment on whether Intel's foray into the realm of ARM and embedded systems is significant? Will anything substantial change as a result of their entry into this already populated market?

(I guess one thing the article mentions is that Quark is potentially more secure than the alternatives. Presumably embedded systems security will be a bigger issue as we approach the future Internet of Things.)

Maybe, if they are able to work the security angle. Industrial embedded folk love to not know about security. Industrial equipment are also usually despised by IT folk. If Intel can give OEMs a standard dirt-simple to configure solution that electricians and HVAC techs can install without screwing up, they might have a horse to race.

>Presumably embedded systems security will be a bigger issue as we approach the future Internet of Things.)

Embedded systems security, or the lack of it, is a big issue now.

Every non-x86 processor from Intel has failed, so there's that.

8051 derivatives are still sold by the gazillions, if not by Intel.

Well, every non-x86-compatible processor anyway. And the article states that the Quark is x86-compatible.

The i960 did ok, and still finds use in some military applications. But, on the other hand, Itanic.

Let's not forget the iAPX 432, which failed far more spectacularly than Itanium. (Itanium even failed at failing, it seems).

Yep. Fond memories of writing an execution trace disassembler for the i960CA back in the early 90s. The chip had an 8-bit incremental trace bus, which made it possible to produce an execution-time instruction trace, as long as the code didn't modify the instructions in memory.

I wrote and instruction scheduler for the i960CA, which was fun. (For those who don't know, the i960CA was the first superscalar microprocessor.) It took assembly code as input and contained (as close as I could get from public docs to) a cycle accurate timing simulator.

Less fun was the associated project of getting the GNU assembler and linker to run under 16-bit DOS. I recall that at the the time the linker consisted of one giant source file, and one of the tools (I think the assembler) contained the wonderful declaration:

    int malloc();


What's the volume on a reasonable sized small batch of chips? How small of an order does it make sense to go down do doing your own chips? If one buys the IP, is it Intel fabbing the chips, or do you have to take the resultant work elsewhere, or is it your option?

Does anyone know how fast this thing runs? Is it comparable to 386, 486, Pentium speeds, etc?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact