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

Re: FORTH plusminus, was Re: [f-cpu] Winograd DCT on my seul.org account



hello,

i don't want to start a new thread but i have to give some explanations.

Andreas Romeyke wrote:
> Hello,
> 
> > > Remember, forth can do this... and surplus you can test forth-code
> > > interactively...
> >
> > Forth is an incredible language but it can't do all i want,
> > or i would use it for a loooong time. It also introduces a lot of things that
> > can interfere with the algorithms, or at least make you forget about
> > what you want to do. Finally, the largest scope that i could globally
> > optimize by hand is 100 or 120 instructions per block. we need to go beyond
> > that. Forth is the contrary of a dataflow graph analysis tool because
> > it over-serialises the computations.
> 
> I disagreed.

do you disagree on the serialisation ?

A stack-based langagae is inherently serial. this is the lethal bottleneck
and it makes the execution on superpipelined + superscalar CPU underefficient
because from 2 to 12 execution "threads" (dependencies) must be handled at a time.
For example, if you have 4 pipelines with 3 cycles of latency, you have to
find 12 operations to perform. Forth's programming paradigm forces this to be 1
in any case because the stack is the critical ressource. Even 4-stack or 5-stack
designs can't solve this problem completely.

> First is Forth only a little more than a MACRO-library of assembler-code.
> Second it is small and easy to learn
mmmm the learning curve is ok but prepare the Aspirin if you're a newcomer...

> 3-th there are forth-dialects coming with an object-oriented manner
> 4-th it is fast enough, compileable and interpretable
not true anymore for superscalar superpipelined CPU. Fortran and C are much faster
on modern computers ...

> 5-th we can implement a forth-interpreter/compiler for F-CPU in much
> easier way than for C and Co.
> 6-th we can test the FC0 as fast as possible
what is the meaning of "fast" here ?

> 7-th We should have the focus on the hardware-site of F-CPU, we need a
> higher language only for testing the core, is not it?
> 8-th we can bootstrap the FC0, it is EPROM programmable
> 9-th we become a set of useful ASM-instructions
> 
> My only disadvantage was, that a mapping of forth-technique to
> register-based cpu could be ineffective, but after some words with
> compiler-developers, should this handable...

it is not "impossible" but the gap is so large that you can't hope the
same level of efficiency as other techniques. Even gcc might make
better binaries :-(

> IMHO all points fullfilled:
> > > - easy readability, easy learning, easy debugging.
Forth is not very readable, at least not for the unexperienced ...

> > > - easy simulation of unimplemented parts (e.g. like
> > >   the test stimulation possibilities in VHDL)
> > > - integrated abstract layer documentation scheme
> > >   that could be extended to automatic code generation.
> 
> An adaption of a special language should be done later.

Forth, at least Chuck's flavor, is a marvelous little thing
but it is not adapted (less than C) to modern CPUs and F-CPU was
not designed to run FORTH code.

Take for example the DCT code i recently published.
how would you code THAT in FORTH ? and then, how would this
translate to machine code ? And what would be the instruction count
with an existing implementation of FORTH ?

What i need is a DataFlow Graph analysis tool that allows me to
handle large chuncks of code with all the automated tedious tasks
that i usually do by hand (register allocation, reallocation,
interleaving...)


> Bye Andreas

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