[LINUX:3321] [Fwd: Freedom CPU project]

Kemal Burak Codur (bbm711@eti.cc.hun.edu.tr)
Mon, 18 Jan 1999 17:56:46 +0200 (EET)


Selam,

Size linux benzeri "acik" bir islemci gelistirme sureci ile ilgili bir
maili forward ediyorum. Yaklasik bir haftadir listeye uye degildim
(listeden atilmisim). Arsive baktim, bu mailin gonderilmis oldugunu
gormedim. Umarim ikinci baski olmuyordur. Bu arada listeden atilma
islemi daha degisik yapilmaz mi? Listeden atilanlarin yayinlandigi bir
URL var mi?

Iyi bayramlar ve iyi calismalar.

KBC

-------- Original Message --------
Subject: Freedom CPU project
Date: Sun, 17 Jan 1999 03:01:57 +0200 (EET)
From: Jukka E Isosaari <jei@zor.hut.fi>
To: beowulf@beowulf.gsfc.nasa.gov
CC: sa-beowulf@kragen.dnaco.net

Hi!

I thought some of you might be interested in following/
participating in this 'open' CPU project. Sounds neat:

http://f-cpu.tux.org/

Here's their FAQ-page:

++ J
------------------------------------
http://f-cpu.tux.org/faq.php3

A GNU/GPLed 64-bit CPU architecture

Philosophy

Q1: What does the F in F-CPU stand for?

A: It stands for Freedom, which is the original name of the
architecture,
or Free, in the GNU/GPL sense.

The F does not stand for free in a monetary sense. You will have to pay
for
the F1 chip, just as you have to pay nowadays for a copy of a GNU/Linux
distribution on CD-ROMs. Of course, you're free to take the design and
masks to your favorite fab and have a few batches manufactured for your
own
use.

Q2: Why not call it an O-CPU (where O stands for Open)?

A: There are some fundamental philosophical differences between the Open
Source movement and the original Free Software movement. We abide by the
latter, hence the F.

The fact that a piece of code is labeled Open Source doesn't mean that
your
freedom to use it, understand it and improve upon it is guaranteed.
Further
discussion of these matters can be found here.

Architecture

Q1: Why did you choose a memory-to-memory architecture? Why not a
register-to-register architecture like all other RISC processors?

A: Basically, for performance: we wanted to improve on RISC, so we had
to
look for a different solution. One of the critical performance
bottlenecks
in modern Operating Systems is the context switch latency, basically
caused
by saving and restoring register sets. The F architecture provides
near-zero context switch latencies. However, there are many RISC-like
ideas
in the F architecture.

We are working on a White Paper which discusses this issue in detail. A
preliminary version can be found here.

Q2: Why an external FPU?

A: This is implementation specific and depends entirely on how many
gates
we can fit in a single 122 mm2 die. The F2 could have up to 4 FPUs on
chip,
since it will be manufactured using 0.18 micron technology. The
architecture only states that up to four FPUs can be used in parallel
with
the main CPU.

Q3: Why don't you support SMP?

A: SMP is an Intel-proprietary implementation of Symmetric
Multi-Processing. In our case, it is not even desirable to implement
shared-bus multiprocessing, because the F1-CPU already has a very high
rate
of bus utilization. Adding more processors would inevitably mean
creating a
bottleneck that would severely limit performance. We opted for a novel
implementation of NUMA-style multiprocessing, which allows both shared
memory (with cache-coherency) and message-passing.

Performance

Q1: Wat can we expect in terms of performance from the F1 CPU?

A: Merced-killer. :-).

Although the F1 CPU will probably run at a lower clock rate compared to
the
Merced, due to improvements in design (geared to achieving very high
levels
of parallelism at execution time) and gcc and kernel-specific
optimizations, it is expected that integer performance will be
comparable
to or better than the Merced.

FPU performance will basically depend on the number of FPUs plugged on
the
CPU bus. With two FPUs the F1 will probably provide better performance
than
a Merced. With four FPUs it should leave the Merced in the dust.

Beowulf F supercomputer implementations should provide superior
performance, because of the exceptional bandwidth and low latencies of
our
NUMA-style multiprocessing mechanism.

Yeah, we know that sounds a little bit ambitious...

Compatibility

Q1: Will the F1 run my DOS software?

A: Maybe. We are planning to build in an x86 emulator in the F1 BIOS.
But
we only want to boot the CPU on standard x86 motherboards. We doubt the
F1
will support sophisticated DOS games and other x86-specific packages.

Q2: Is the F1 CPU Windows (98, NT) compatible?

A: No. It will not run WINE either.

It should however run Windows emulators that include x86 CPU emulators
such
as Twin, as well as Windows itself under whole-PC emulators such as
Bochs.
In either case however you will need to run another operating system,
such
as GNU/Linux, and emulation will likely be fairly slow.

And of course there is the slight possibility that Microsoft will port
Windows NT to the F1, but I wouldn't hold my breath. ;-)

Q3: Will I be able to plug the F1 in a standard Socket 7, Super 7 or
Slot 1
motherboard?

A: In principle, yes. This is one of its design parameters.

Your motherboard will have to support the 2.2V rating of the F1 CPU, and
there may be other requirements/limitations. But in principle there is
enough bus bandwidth in a 100 MHz Super 7 or Slot 1 motherboard to
support
a high-performance CPU like the F1. 66MHz Socket 7 motherboards will be
supported too, but their performance will be somewhat limited.

Q4: What OS kernels will the F-CPU support?

A: Linux will be ported first, and MkLinux will perhaps be ported too
later
on. A port of Linux will be developed simultaneously with the F1 CPU
development.

We will first port gcc to the F architecture. Basically the F1 will run
all
the software available for a standard GNU/Linux distribution.

Features

Q1: What kind and size of caches will the F1 CPU have?

A: Internally, the F1 will have Harvard-style separate caches for
instructions and data. We are planning on 64KB 4-way set associative L1
caches (one each for data and instructions). We also have small L0
caches
for instructions (512 bytes) and data/virtual registers (8KB).

Cost/Price/Purchasing

Q1: How much will the F1 CPU cost?

A: Our estimates are that an F1 CPU will cost approximately US$100.

See our detailed cost estimate if you don't believe us!

Listeden cikmak icin:
unsub linux
mesajini listeci@bilkent.edu.tr'a gonderiniz.
Lutfen Listeci icin MIME / HTML / Turkce Aksan kullanmayin.
Liste arsivinin adresi: http://listweb.bilkent.edu.tr/