[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] F-CPU architecture...
hi,
Michael Riepe wrote:
Moin!
plus !
Tobias Bergmann wrote:
Oh I forgot to mention: A collegue of mine is writing a OS tool for
circuit simulation, synthesis, ATPG, fault sim, ...
It's called signs:
http://www.iti.uni-stuttgart.de/~bartscgr/signs/wiki/index.php/Main_Page
Already noticed that on freshmeat.net :)
But I didn't look at it yet.
have a look whenever you can, as it may help you,
it seems to be complementary to your own work.
[...]
How large would the effort be to add SMT to the FC0 core? I'm
thinking of approx. 3-fold SMT.
Too high, IMHO. In particular, the required changes to the register
set and crossbar would be real speed killers.
certainly.
now comes the real "meat" in this mail :
I recently had an idea for light-weight parallel execution - let's
call it "threadlets". By adding explicit fork/join instructions, an
application could split itself into threadlets if it sees fit. Of
course careful programming would be required because threadlets share
the same register set.
The basic idea is that there is a variant of the jump instruction
(with two arguments), called "fork":
fork r2, r1
That will fork a threadlet starting at address r2 and return some kind
of threadlet "ID" in r1. Now both the main program and the threadlet
can work independently. When the threadlet is done, it will execute a
"return from threadlet" instruction. The main program can use the
"join" instruction
join r1
to wait for termination of a particular threadlet, or
join r0
to wait for all of them. To ease implementation, only the main program
will be allowed to fork threadlets or execute special instructions
like syscall or get/put.
Note that the core is not required to process threadlets in parallel
at all. If support for parallel execution is missing, threadlets will
be executed sequentially, in any order (or lack of order, as you like
it). In the most simple implementation, the "fork" instruction would
turn into a subroutine call (that is, "jump r2, r1"), and "join" would
be a no-op.
On the other hand, a core may execute as many threadlets in parallel
as it can. All we need to provide is an IF&D unit that supports
multiple instruction streams.
after 5 minutes, i came to this conclusion :
SMT or threadlets can certainly be done in FC1, but not in FC0.
your idea is quite smart, but beside support from compilers, a more
pragmatic
issue arises : it goes against one of the core ideas in FC0.
specifically, we can avoid delayed branches and branch prediction because
a taken branch has very low penalty (1 cycle today). This is because as soon
as an instruction is selected by the Fetcher, it goes directly to the
register set's 3 address
buses, so the data is available on the next cycle (ideally, which is
also half the time
it takes to decode and issue the instruction).
Now, adding support for multiple instruction streams (whether they share
or not the register set)
adds a minimum of one stage : the instruction must be selected among the
threads,
and this decision is ideally based on resource availability (is the
register's value available
somewhere on the Xbar or is the LSU ready ?).
This minimum additional stage doubles the branch penalty and breaks the
architectural balance.
Of course, this penalty can be spread among the running threadlets, but
i don't believe in
this ideal scenario because the other threadlet (that will mask the
branch penalty) MUST
have 2 completely independent instructions which don't stall AT THIS
EXACT MOMENT.
Adding a third and/or fourth threadlet will only bring the complexity
and die surface higher,
and compiler support is not even here.
I propose that we finish FC0 the way we designed it almost 5 years ago,
and then we can move to more sophisticated stuffs :-) I believe that FC1
will be quite exciting but it will be impossible untill we finish FC0.
@+
YG
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/