[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[f-cpu] I'm still in the warmup phase ;-)
- To: firstname.lastname@example.org
- Subject: [f-cpu] I'm still in the warmup phase ;-)
- From: Beat Steiner <email@example.com>
- Date: Thu, 13 Nov 2003 12:13:00 +0100
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivery-date: Thu, 13 Nov 2003 05:55:40 -0500
- References: <126.96.36.199.1.20031113070812.00a1d6d0@ pop.t-online.de>
- Reply-to: email@example.com
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010923
Thilo Reichelt wrote:
OK. Let's abandoned ideas be abandoned. Otherwise we won't make any
TTA was abandoned long ago.
Please see http://f-cpu.seul.org/manual/ for more recent information.
The manual has such a nice increment unit. It would be almost a pity to
replace it by add units.
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).
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
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
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
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
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 email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/