Toward An FSF-Endorsable Embedded Processor
lkcl writes about his effort to go further than others have, and actually have a processor designed for Free Software manufactured: "A new
processor is being put together — one that is
FSF Endorseable,
contains no proprietary hardware engines, yet an 800MHz 8-core version would,
at 38 GFLOPS, be powerful enough on raw
GFLOPS
performance figures to take on the 3ghz AMD Phenom II x4 940, the
3GHz Intel i7
920 and other respectable mid-range 100 Watt CPUs. The difference is: power
consumption in 40nm for an 8-core version would be under 3 watts. The core
design has been proven in 65nm, and is based on a hybrid approach, with its
general-purpose instruction set being designed from the ground up to help
accelerate 3D Graphics and Video Encode and Decode, an 8-core 800mhz
version would be capable of 1080p30 H.264 decode, and have peak 3D rates
of 320 million triangles/sec and a peak fill rate of 1600 million pixels/sec.
The unusual step in the processor world is being taken to solicit input
from the Free Software Community at large before going ahead with putting
the chip together. So have at it: if given carte blanche, what
interfaces and what
features would you like an FSF-Endorseable mass-volume processor to have?
(Please don't say 'DRM' or 'built-in spyware')."
There's some discussion on arm-netbook. This is the guy behind the first EOMA-68 card (currently nearing production). As a heads ups, we'll be interviewing him in a live style similarly to Woz (although intentionally this time) next Tuesday.
ok more than a little.
The guy who said the election was rigged won the presidency with the second-most votes.
I couldn't care less if it is x86 compatible (I assume it is emphatically not). I'm sure the FSF does not care, either. I would use this in a heartbeat for my main desktop, and since I haven't had any significant dealings with Windows in at least 8 years, all I need is a free Posix OS (probably linux) and a C/C++ compiler.
pay attention 007: we're aiming for mid-2013
Yes, that's what I said:
* The proposal is dated December 2, 2012 for an advanced kitchen sink SoC with silicon in July 2013? Really?
Perhaps my phrasing was unclear. I am skeptical of a six-month development process.
also, bear in mind: the core design's already proven.
By who? To what specs (temperature, voltage, operating life)? Using what methodology?
mid-2013, whilst pretty aggressive, is doable *SO LONG AS* we *DO NOT* do any "design" work. just building-blocks, stack them together, run the verification tools, run it in FPGAs to check it works, run the verification tools again... etc. etc.
You know you can't go straight from RTL to silicon, right? You need timing sims and physical layout. Those are not trivial and they cannot be totally automated.
the teams we're working with know what they're doing. me? i have no clue, and am quite happy not knowing: this is waaay beyond my expertise level and time to learn.
Okay, here's the part that confuses me. You came up with an idea, talked to other people with expertise about doing it, and it sounds like you know who's working on it. All of that is fine. What I don't understand is why you are acting as the leader/spokesman for a project you know almost nothing about. Who are these other groups? The link at the bottom of your proposal is to a no-name Chinese semiconductor company that formed last year and has no products listed. Are they doing the RTL, layout, and verification? Who's doing the silicon testing? What foundry will you use?
The reason I'm being so harsh here is because you're asking for a lot of money with very little credibility. There is nothing in your proposal, your CV, or your comments to suggest that you are competent to work on a project like this. So who's doing the work? Why aren't their names on the proposal? Who has the experience and leadership to make sure the project actually gets done? Why are you "quite happy not knowing" what they're doing when you're the one trying to secure funding?
If you come back here in 2013 with a working chip I'll be the first to apologize, but right now I see very little reason to take this seriously.
Visit the
Yes, we can move away from x86.
No, it isn't a good idea.
It's time to put this one to rest.
It's been a few decades and we've seen the argument from theory, practice, and to conclusion today.
x86(and it's er.. extension/evolutions) IS the better general purpose arch. But not for the reasons anyone conceived of. I think it's best put this way.
1. RISC(for example) very good at running good code.
2. Most code is bad. (No really, it's awful. Ask any programmer)
3. x86 processors, it turns out, are very good at running bad code.
Many other arches were created under the premise that good code could be created for them automatically. Turns out that compilers that can do this are like unicorns. They don't exist. It's an np-hard problem.
It's what killed itanium. The magic compilers never turned up. The amount of developer effort required to write good software isn't worth it.
*Why is most code bad you ask? Easy. Programming, put crudely, is a bullshit art.
Just ask Dijkstra (Well not anymore. He's dead now) Programs are math. Few programs, however, are proven to be "correct" mathmatically. - It's impractical for most applications. Sure, you have rules you call "Practices" that tend to generate better code.. But everyone knows how code is really developed nowadays. Lay it down, slap it around until the show stoppers are reduced to a bearable frequency, and patch up anything you missed after it ships.
I'm not saying this approach is necessarily bad. It has advantages. It's very fast! It's fast, and you can get a lot of useful work out of it. If your idea or application is good or novel or productive enough you can put up with some bugs and at the end of the day you'll end up ahead. - If you set out to write a program that's mathematically prove-able from start to finish.. Your competitors will have buried you years before your first release.