[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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/