[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE : [f-cpu] Snapshot_jws update



hi !
just before i fall asleep...

jaap stolk wrote:
> hi,
> 
> --- Yann Guidon <whygee@f-cpu.org> wrote:
> > seems this idea of a SW C simulator triggered
> > some interest.
> don't spent to mutch time on a simulator, a real
> F-CPU would be a lot nicer :-)
i am working on a model, be it in VHDL or C...
i am also continuing the work on a C version
(i did that before but the method was flawed).

> to make sure we don't spend to much time doing the
> same thing, i tried to implement all suggestions,
> and reply to all questions ASAP.
> i also uploaded a new snapshot_jws.
i gotta check it now ;-)

> >about ncurses:
> looks very useful, but i will save it till the
> simulator needs more user input. (dous a simulator
> need any input, apart from selecting different views?)
> i now use a gnome x-terminal of +/-60 lines,
> so i can see the last state as well.
i'm working in text mode, but in a 800*600 framebuffer
with 8*8 font : i got 75 lines and 100 columns ;-)

> >getkey.c:
> i'll use it until i start on ncurses.
> it was just what i needed.
> thanks Thomas.
i can't find anything about it on my linux box.
where and how is it provided ? is it outside of
the libc ?

> i made some changes:
> -changed carriage returns from MSDOS to UNIX type
> -moved jaap.txt to f-cpu/c/
> -only scripts appear as executable
> -added YG's register .c / .h and test_registers.c
> -reordered register.h
> -added flags to register_view.c
> -added "print(true/false)" function
> -created /c/fcpusim/ and split the files into:
>  toplevel.c -> link al units (i.e. simulate)
>  fcpusim.c  -> interface, (was fcpusim_view.c)
> -added getkey.c
wow, i gotta upgrade my snapshot again...

> todo:
> -make more connections between units stall-able.
maybe i'm too low-level, but what's the use of connecting
things that are not yet working ?... the Xbar is a difficult
design so be careful.

> -add counters for IMUL and IDIV to scheduler.
? since IMUL can be pipelined, there is no need of a counter
is the Scheduler Queue : the queue must be as deep as the IMUL
unit (as IMUL is the largest pipelined unit). there would be
only one counter (for IDIV).

> -and a lot more..
let's make things work and verify them :-)

> and some more reply's:
> 
> >but a YG snapshot is necessary if some definitions
> >must be changed.
> i'm still using a YG snapshot to change definitions
> i will try to add the script soon.

beware ! i found a typo on f-cpu_types.h.
a comment is not closed.

> >i would concentrate on
> > - validation of the units
> > - careful design and validation of the register set
> > - and then connect the units together with the Xbar.
> > - then comes the decoder and the scheduler queue.
> but it's more fun to do it all at once :-)
maybe, until you see that nothing fits with the rest...
of course, it's interesting to "play" with the units,
in order to see how it works as a whole. but it won't
work correctly without some planification. Even though
this planification needs one to try things, but these
attempts can't work as is. That's why my last attempt
was called "QDCPOC" and as a result, i started coding
the langage-independent configuration engine with m4...
Now i continue the work by adding another functionality
(the cross-langage tests). When all the tools will
be ready, we will be able to make really good code
(at last) that will require less maintainance.

> >i have remarked that you have not integrated ROP2
> i (or YG?) will do it soon. connecting EU's is easy.
i'm doing this currently, simply because i usually
maintain this small (but interesting) part and
i integrate new tools this way...

> >I also remark that EU_INC is not capable of doing SIMD
> >operations.
> .. as well as a lot of other things.
> supporting SIMD is not on the top of my list...
> i just looked at GMP, would this we useful for doing
> 64 / 128 / 256 bit ?
GMP is huge and not really useful (we don't care about
99% of the functionalities). all we need is a compile-time
precision (while GMP is dynamic) and a dozen of functions
(add, copy, or, and, xor, not...) on SIMD data...

> > "clocking" / reduce temporary variables..
> i spotted the possibilities, and there are a lot of
> other things that can improve speed, but for now i
> like the "clocking" / "copying" because it's easy and clear.
> i now shift the scoreboard every cycle, how is that for
> slow simulation! :-)
not a big problem however. "Alles is relativ" :
if you don't shift something, something else has to move...

> as soon as it is (mostly) working a will take a closer
> look at speed.
:-)
my worries now (as always) :
 - make it work
 - make it perfectly clean (absolutely kludge-free)
 - make it scalable (no need to hack it when something else changes)
 - and prove it, whatever the langage.
That's why i spend a lot of time tidying stuffs,
making scripts and tools, so it's so much easier
to make clean code after that :-)

happy hacking, but be careful.

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