F-CPU

F-CPU

Post by Whyge » Tue, 23 Nov 1999 04:00:00



hmmm,

usually this kind of post gets subconsciously
trashed by the regular posters of this ng.

but now i think that there is something good
enough to require more public exposure. at last !
because this lasts for almost two years, and we have
finally come to a rather decent definition.

This is called the F-CPU, a GPL'd platform that
is currently being created. A pseudo-RISC
(argh ! what a word !) CPU with 64 internal
general purpose registers and of course 32-bit
wide instructions and virtual memory capabilities.
that's for the outline.

For the whole background, and because i can't write
everything here, go browse the "official" site
at http://f-cpu.tux.org and read the manual
( http://f-cpu.tux.org/manual/summary.html )
(that is being written by my sore fingers).
or simply get the latest version zipped at
http://www.mime.univ-paris8.fr/~whygee/fcpu_manual.zip

We are currently discussing the instruction
set and unfortunately, of the 200 bozos subscribed
in the mailing list (egroups...) only a few speak
out and so i am doing most of the work with Mathias.
So in fewer words, we need help, hints, advices,
more participations, new heads, more support,
more and more recognition and soon, access to
a BIIIG FPGA.

Read the manual, subscribe to the mailing list.
we don't ask money :-)

read you soon,
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html

 
 
 

F-CPU

Post by Zalman Ster » Wed, 24 Nov 1999 04:00:00


: usually this kind of post gets subconsciously
: trashed by the regular posters of this ng.

Perhaps. Every time I go try to read the F-CPU stuff I'm struck that the
project has not clearly separated the job of defining an architecture from
lots of other things, like detailed speculation about implementation and
kvetching about existing architectures. Its fine to have a rationale
alongside your architecture spec, but it is not fine to have an
architecture spec that spends half its words editorializing on all the
architectures that have gone before.

This is purely a matter of communication. You have powerful tools at your
disposal to deal with these problems as well. For example, you can
hyperlink from the architecture specification to the rationale. You might
even consider formal methods of specifying the archtiecture. Or perhaps
hyper linking between the source code for the F-CPU simulator and the
archtiecture spec, etc.

Think of architecture specification as a very hard programming job, not
like writing a really long netnews post...

-Z-

 
 
 

F-CPU

Post by Jonathan Thornbu » Thu, 25 Nov 1999 04:00:00


: usually this kind of post gets subconsciously
: trashed by the regular posters of this ng.



Quote:>Perhaps. Every time I go try to read the F-CPU stuff I'm struck that the
>project has not clearly separated the job of defining an architecture from
>lots of other things, like detailed speculation about implementation and
>kvetching about existing architectures.

>[[...]]

>Think of architecture specification as a very hard programming job, not
>like writing a really long netnews post...

As well, I was surprised to find no mention of Donald Knuth's "MMIX"
project, another free RISC architecture currently under development.
Given Knuth's reputation, and the assistance he's getting from MIPS
and Alpha designers, IMHO anyone designing a new RISC architecture
should be familiar with MMIX, and I think F-CPU would be well advised
to include material on their web pages "comparing and contrasting"
their design with Knuth's.

For those not familiar with MMIX, here's a brief summary quoted from
http://www-cs-faculty.stanford.edu/~knuth/mmix.html
|    MMIX is a machine that operates primarily on 64-bit words. It has 256
|    general-purpose 64-bit registers that each can hold either fixed-point
|    or floating-point numbers. Most instructions have the 4-byte form `OP
|    X Y Z', where each of OP, X, Y, and Z is a single 8-bit byte. If OP is
|    an ADD instruction, for example, the meaning is ``X=Y+Z''; i.e., ``Set
|    register X to the contents of register Y plus the contents of register
|    Z.'' The 256 possible OP codes fall into a dozen or so easily
|    remembered categories.
|
|    The designers of important real-world processor chips (e.g., MIPS and
|    ALPHA) are helping me with the design of MMIX.

--

   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "Stocks are now at what looks like a permanent high plateau" -- noted
      economist Irving Fisher, 2 weeks before the 1929 stock market crash

 
 
 

F-CPU

Post by Bernd Paysa » Sat, 27 Nov 1999 04:00:00



> As well, I was surprised to find no mention of Donald Knuth's "MMIX"
> project, another free RISC architecture currently under development.
> Given Knuth's reputation, and the assistance he's getting from MIPS
> and Alpha designers, IMHO anyone designing a new RISC architecture
> should be familiar with MMIX, and I think F-CPU would be well advised
> to include material on their web pages "comparing and contrasting"
> their design with Knuth's.

Yeah, MMIX is IMHO a lot better than what I read of F-CPU. It's somewhat
boring (after all, it's more a rehash of what exists than something
new), but that's the purpose. The only gripe I have is that 256
registers are simply too many to utilize in a useful way, and too many
to implement in a small design (this is 2K for a unified register file,
and don't forget: you need some hidden ones to implement the IA64-like
register stack).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

 
 
 

F-CPU

Post by Mathias Brossar » Sun, 28 Nov 1999 04:00:00



> As well, I was surprised to find no mention of Donald Knuth's "MMIX"
> project, another free RISC architecture currently under development.
> Given Knuth's reputation, and the assistance he's getting from MIPS
> and Alpha designers, IMHO anyone designing a new RISC architecture
> should be familiar with MMIX, and I think F-CPU would be well advised
> to include material on their web pages "comparing and contrasting"
> their design with Knuth's.

        Just because it's not written doesn't mean we haven't
looked at MMIX. My personal opinion of the MMIX is that it is,
like the MIX was, only useful for Knuth's book.

Mathias

 
 
 

F-CPU

Post by Jonathan Thornbu » Mon, 29 Nov 1999 04:00:00




[[people should know about Knuth's MMIX architecture,
   http://www-cs-faculty.stanford.edu/~knuth/mmix.html  ]]



Quote:>Yeah, MMIX is IMHO a lot better than what I read of F-CPU. It's somewhat
>boring (after all, it's more a rehash of what exists than something
>new), but that's the purpose. The only gripe I have is that 256
>registers are simply too many to utilize in a useful way

That does seem like a lot, but Knuth obviously wants an architecture
with some headroom from growth.  Compilers are gradually getting smarter,
and can effectively use more registers.

Even today, some number-crunching code would *love* to have a couple
of hundred floating-point registers.

Quote:> too many
>to implement in a small design (this is 2K for a unified register file

Any modern high-performance chip will have a lot more than 2K bits
worth of on-chip cache.  Granted a register file uses a lot of transistors
for multiporting and bypassing, but then again, a cache uses a lot of
transistors for tags (and maybe bypassing these days).

Quote:>and don't forget: you need some hidden ones to implement the IA64-like
>register stack).

Does MMIX have a register stack?

--

   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "Stocks are now at what looks like a permanent high plateau" -- noted
      economist Irving Fisher, 2 weeks before the 1929 stock market crash

 
 
 

F-CPU

Post by Bernd Paysa » Mon, 29 Nov 1999 04:00:00



> Any modern high-performance chip will have a lot more than 2K bits

2K bytes, that's 64 bit*256. I've no objection against 2K bits.

Quote:> >and don't forget: you need some hidden ones to implement the IA64-like
> >register stack).

> Does MMIX have a register stack?

Yes: you have a special purpose register which tells you where the
register stack starts (the previous registers are global), and you have
enter/leave instructions that change the stack pointer and automatically
fill/spill registers.

However, if I think a bit longer about that, I won't implement the
register file at all for a cheap solution. Use a cache for the registers
and let those registers that are not needed migrate to memory.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/