[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] Status quo
Le 2015-03-28 19:05, Nikolay Dimitrov a ÃcritÂ:
Hi Yann,
Hello Nikolay and everybody,
I'm struggling to restore decade-old backups
to recover the old email archives and credentials.
Meanwhile, I reply to this mess&age and others,
because 1) each email that goes to the list creates
many error messages in my mailbox
2) several people are annoyed by receiving our messages...
On 03/28/2015 03:45 PM, whygee@xxxxxxxxx wrote:
It always starts like this ;-)
Do you remember OpenOEM? Most people probably haven't even heard of it.
And no, don't open Google to find it, because it's dead for probably
7-8+ years. It was a group that wanted to build a fully open and free
hardware platform. Well, in the course of 1-year discussions I finally
asked the group the right question: what would you choose, freedom or
performance? For me this is a fundamental question that has to clarify
the motivation of each participant.
I personally think that the F-CPU reboot should put some clear
high-level project guidelines that everyone should agree on, just to
keep project on track and moving forward.
These are very very good points.
What is happening now is : my YASEP microcontroller core will be
"decently working" and used for professional projects in a year or two
(I know, I say this every year). I have a need for the YASEP, and it
helps me prototype tools and try new methods. There is a big affinity
with some F-CPU ideals and the YASEP is created to be totally compatible
(license, tools, etc.). When enough is ready, this could help the F-CPU
project to move forward much more easily.
However, it's a _personal_ endeavour. I have most of the necessary
resources
to do it, probably with a couple of other people, and since it breaks
a couple of points in the F-CPU constitution of 1999, it should be
considered as a _fork_. I even wonder if I should still call it F-CPU at
all,
but I'll reuse a good part of my past work, mainly the instruction set
and a refreshed FC0 core.
To answer your question, I believe and I have witnessed again and again
:
freedom trumps performance. Performance is useless when you can't use
it.
Freedom in the context of F-CPU, in practice, means many compromises
(and endless discussions) so freedom does not lead to performance...
But I hope to fix that part too.
An even deeper and equally important question is : why do we need
freedom
and to do what ? Freedom is an ideal and the team has surfed on it but
it can go nowhere if there is no strong market backing and a whole
infrastructure that works. That's another thing that I've been working
on
and I've gained more skills and tools. However the YASEP was born
because
I needed it for practical purposes and actual projects, it was meant to
be
part of a product. But there is no such thing for the F-CPU and the
mindset
is still stuck in the Y2K era of the PC mainboards with CPU, memory and
I/O...
The F-CPU project is "hard" because it requires many things before and
after it,
on the electronic side and on the software side. It is what we would
call today
an "application processor" and I have no need for it yet. The YASEP can
do
most of what I need these days, which is mostly embedded stuff. The
F-CPU won't
take off without a matching project for a computer, indeed.
This reminds me of our long email discussions (and I really thank you
for your outstanding patience to all my "smart" ideas :D). I do realize
that it's hard to look at all modern CPU architectures and not to want
one or more design or implementation ideas included into your hobby CPU
architecture. But we need to be realistic.
I agree.
Sometimes less is better (one such example is MIPS).
Which leads me to one proposal: to improve the SNR of the discussions
and reduce the disappointment of people suggesting ideas, let's invent
a simple rule: suggest only things that *you can implement now*. Which
usually means - think twice before giving ideas, because you could be
the one leading their implementation.
What do you guys think?
I wish more people agreed :-)
But many people seem to have another urge : to come back to the
foundations and
want to change this or that, without concern of all the required updates
to the manual and other existing documents. We have an instruction set,
that is the result of endless discussions, and after we've come to a
consensus,
somebody else comes and wants to do something else.
So it's not enough to ask for proposals that can be implemented now.
its not enough either to request people to actually implement themselves
the changes they propose, even if they say they're ready to manage all
the changes in tools, manual, website etc... The "wiki" mindset has led
to a design that can't progress because once somebody writes code based
on already agreed features, it gets undermined by changes from other
people,
and others wouldn't want to create whole code bases on a shifting spec.
That is why I intend to manage my "fork" in a more Linux-like way.
Bikeshedding has cost us too much time and many subscribers are tired of
drama.
Kind regards,
Nikolay
YG
Le 2015-03-28 21:49, Nikolay Dimitrov a Ãcrit :
Imho using libraries like GMP is a necessary evil so you can achieve
your diverse requirements on a general-purpose CPU. Otherwise you'll
need a very strange CPU that can achieve "everything" through
specialized CPU instructions - handling SQL queries, garbage
collection, TCP socket handling, image scaling, video compression &
decompression. This is not realistic.
right.
And F-CPU is RISC, a well-misunderstood design philosophy...
Even if you implement such CPU, it would be incredibly expensive and in
most of the use cases the users won't use most of its features. Talk
about inefficiency.
Today all high-performance designs have either a co-processor or
special application accelerator (usually an IP-core attached to one of
the buses). For your case, you can design an arbitrary precision BCD
accelerator. This will both allow you to calculate faster, and leave
the CPU design... well, generic :D.
You raise the question of coprocessors and it's a very important matter
that also influences my new "vision" of the F-CPU evolution.
More and more designs couple a CPU with coprocessors (more or less
generic ones)
and GPGPU is spreading all over the map.
F-CPU was meant for "high performance" and number crunching,
but this is and should now be relegated to the array of generic
coprocessors. This leaves the real "application" to the F-CPU,
this is how and why I aim at a leaner FC0.
So, what is the main design goal of the f-cpu?
it was in the constitution, yet now i realise it was missing a few
critical
details that make it moot today...
Freedom. Like freedom to make the right design choices, freedom for
everyone to get the design, change it for their needs and redistribute
it at will. It looks like a good enough motivational factor for quite a
bit of people, contributing to all the libre software and hardware
projects around the globe.
That part has not changed in my opinion :-)
Developing a damn cool cpu is a hard job.
it's hard because everybody has their own feelings and understanding of
"cool".
F-CPU is still associated to "cool" because it appeals to our individual
fantasies...
This is one more reason to "fork" and find a new name for my design.
But taking a lot of our spare time to develop,
implement, test, program a cpu which is far less state-of-the-art like
some other cpus is not that motivating. It should be better than every
other cpu, I can buy.
"better" in what respect ?
no CPU can be better in ALL domains.
it's a lot of compromises.
the Alpha compromises many "comfort" instructions for raw speed.
the x86 compromises die area for compatibility.
Now, what should we compromise for freedom ?
As I already said, it's always like this: choose freedom vs
performance. Whatever your choice is, I'll respect it.
I agree again.
Btw, people have somewhat romantic understanding about the current
state of affairs - that every commercial CPU is working perfectly and
is documented perfectly.
[...]
And what about security - can you trust you
CPU, when it's running a black-box UEFI BIOS and has access to all your
resources?
Exactly and this VERY important problem was already latent when the
F-CPU
project was started.
15 years ago there was no other free cpu, so it was the first of it's
kind. But today there are some other free cpus like the OpenRISC 1000
and is successor the OpenRISC 1200. Meanwhile running with ported
linux
kernel and libc. You can find them on opencores.org.
Just for the record : the OpenRISC is in another ballpark,
more or less a MIPS-like CPU. It's an easy undertaking,
given all the tools and documentation for Patterson & Hennesy.
the F-CPU was to be a "very high performance CPU",
with more influence from the Alpha design. 64 registers
and at least 64 bits for very high throughput. OR can't do that.
Just to clarify:
- DLX was published in 1996, in Patterson's & Hennesy's book "Computer
architecture - a quantitative approach" 2nd edition
- LEON SPARC v7 core was started around 1997
- Jan Gray published XR16 and some other design ideas around 2000
- Plasma was published in 2001
- Yellow Star was designed around 2000-2002 and report published in
2002 (when MIPS Technologies threatened the author and OpenCores for
copyrights violation).
yup, though I'm not sure about the DLX date.
Looks like the idea for soft-core CPU was already in the air when F-CPU
started, but Yann can correct me on this.
let's move to comp.arch then ;-)
Regarding the state of OpenRISC - I agree that the OpenRISC team has
gone a long way to achieve their goals and I deeply respect them. And
there are also other freely available CPU core designs, like
LatticeMico32, MicroBlaze-compatible CPU cores like aeMB and OpenFire,
and even some ARM-compatible cores (well, with old ISAs because ARM is
prosecuting everyone making implementations compatible with the newest
ISAs). Which is very nice because we can learn/evaluate/change them,
and even design something new based on similar ideas. Again, freedom of
choice.
yup,
OpenCollector had a nice list as well, but there are some examples there
http://en.wikipedia.org/wiki/Soft_microprocessor
Shouldn't it be better than that?
Well, imho the design and it's implementation is as good as the team
behind it. The proper question is - are we good enough to make a better
design than the other teams did :D?
and before that, before making something "better", shouldn't we be doing
something to begin ? My "toy" CPU has been designed in this mindset
so i feel ready to go further now.
Kind regards,
Nikolay
yg
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/