[f-cpu] I'm still in the warmup phase ;-)

[Beat Steiner <linux@iprolink.ch>]

Thilo Reichelt wrote:

> TTA was abandoned long ago.
>
> Please see http://f-cpu.seul.org/manual/ for more recent information.
OK. Let's abandoned ideas be abandoned. Otherwise we won't make any 
progress.

> > Other suggestion I would like to make:
> > One register has already been reserved for constant 0
> > The same way, a register for +1 and -1 could be reserved.
> > This way, increment and decrement could be replaced by additions.
> > The -1 constant (0xFFFFFFFFFFFFFFFF) is also interesting in 
> > conjunction with EXOR
> > to negate a value. Maybe the +1 register is even not necessary 
> > (replace by subtract -1).
The manual has such a nice increment unit. It would be almost a pity to 
replace it by add units.
But two add units may be better than one add and one increment unit. Is 
the find-first-lsb relevant
to any software? Hash/compression algos or such?

Do we need more pseudo-registers for memory access?

What about a GREP engine? Suggested operands: byte to match, mask of 
bits to match, register to search.
Could find the character "p" in the 8 char string "f000-cpu" in some 
clock cycles. Hmm. Was just an idea. We first
should get a simple design running before adding fancy engines.

Was there already an attempt to implement an f-cpu with CPLDs (complex 
programmable logic devices)?
If we could couple maybe some 100 CPLDs (FPGAs or whatever), the design 
could be easily tuned,
debugged and corrected, without carving anything into silicon.
We won't be faster than a pentium pro (clock freq about 33 to >100 
MHz?), but the design process
is significantly simplified. Simulation software is nice, but I prefer 
HW -- its somehow more fun :-).

Is there already a doc available about the f-bus?
It would be nice to issue read requests asynchronously to the data 
returned. Responses must be priorized
over requests.

Example (T=start time, CC=clock cycle):
T+00CC: R01 := [0x000000da00012000]
T+01CC: R02 := [0x0000fe00263785000] does not wait for the above 
instruction to complete and already issues
       the next read request. Every Memory module will need a queue for 
that. Banking of RAM chips no more
       required. All may have different size (and even speed).
T+16CC: Result for R01 := [0x000000da00012000] drops in and is stored in R01
T+20CC: Result for R02 := [0x0000fe00263785000] drops in and is stored 
in R02

Is such an OOO (out-of-order) bus design already patented as DDR, 
RAMBUS, Chipkill or whatsoever?

Sorry for the above opcode. But I somehow prefer R01 := R02 + R01 to ADD 
R01, R02.

Some things to remember:
* Most important design rule: keep it simple.
* The majority of computer users needs rather data movers than computers 
(i.e. machines performing calculations).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail is distributed under the terms of the GFDL, or "GNU Free 
Documentation License",
which can be found on the GNU web site http://www.gnu.org
Copyright (c) 2003 by Beat Steiner. Permission is granted to copy, 
distribute and/or modify this document under
the GNU Free Documentation License, Version 1.1 or any later version 
publshed by the Free Software Foundation.


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/