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

Re: [f-cpu] RC5, F-CPU and srotl



I knew FORTH as being in fact a mix of compiled and interpretable code :

Usually, a FORTH code is a sequence of call addresses (there is no opcode but
just address), so it is more compact than a native code. Everytime you create a
FORTH function (I'm not sure about the exact term to use), there are two
possibilities : a native code (ASM) or a FORTH code. So you still need a
monitor :

    loadaddr 0f,r62
    movi $4, r58
    movi $2, r57
    loadaddr 1f,r56
    loopentry r54
0:sub r58,r60,r60                      // --rsp
    load r61,[r60]                         // ip = *rsp
    if (r61 == 0) jump r0,r55        // if (ip == 0) goto 0
1: load r59,[r61+]                       // next_ip = *ip++
    and r59,r57,r54                      // not_native = next_ip & 2
    if (r55 == 0) jump r0,r59        // call next_ip
    sub r57,r59,r61                      // ip = next_ip - 2
    add r57,r59,r59                      // next_ip = next_ip + 2
    store r59,[r60+]                      // *rsp++ = next_ip
    jump r0,r62                             // goto 1
2:...

(here I suppose we code a native code to terminate a forth code, so I don't
check for return stack boundary)

r63 = sp (stack pointer - used by both native and forth code)
r62 = rp (return pointer - used only by native code)
r61 = ip (instruction pointer - used only by forth code)
r60 = rsp (return stack pointer - used only by forth code)

I did create a virtual machine, that is, a FORTH-like CPU. That was great but
not the point for F-CPU.

Of course we could in fact generate only native code but it will generate
(without registers optimization) at least two instructions (if I'm not wrong)
to call one forth address :

    loadaddr $function1,r61
    jump r62,r61
    loadaddr $function2,r61
    jump r62,r61
    loadaddr $function3,r61
    jump r62,r61
    loadaddr $function4,r61
    jump r62,r61
...
----- Original Message -----
From: Yann Guidon <whygee@f-cpu.org>
To: <f-cpu@seul.org>
Sent: Tuesday, April 16, 2002 9:53 AM
Subject: Re: [f-cpu] RC5, F-CPU and srotl


> hi !
>
> just a few quick notes...
>
> Ben Franchuk wrote:
> > Andreas Romeyke wrote:
> > > Hello,
> > >
> > > > - a FORTH interpreter
> > > That is a very well idea. forth is easy to learn, forth-programs are easy
> > > to debug and a forth-interpreter is easy to write. And forth is a good
> > > point to start experiments with development on F-CPU...
> > >
> > > But, could we really map a stack-based language to a register-machine
like
> > > F-CPU is?
> > Easy answer maybie. The F-cpu has no problems with stacks, the problem
> > is that most machines have deep pipelines (like the F-cpu)
> i don't think that FC0's pipeline is such a deeply pipelined computer.
> In some situations, the pipeline is shorter than a plain Pentium
> and it's much simpler than a P2 or P3.
>
> This makes me think that adding register renaming or even register bank
> switch/rotation to FC0 will add a pipeline stage or two, break the schedules
> and explode the jump latencies. This is one of the reasons why i want to keep
the
> core as simple as possible, without bells and whistles (such as loadm and
storem).
> If "indirect" register bank accesses are necessary, the bank access is
> performed only at the fetch stage (so the fetched instruction is blocked for
a cycle).
> </just a note>
>
> > and Forth is
> > known for bouncy code flow and data access that really mess up a cache.
> it is also known for requiring a small footprint :-) so if your cache is
> large enough (and if your L2 can sustain the load), the problems will
> come from somewhere else (but we'll have to measure this).
>
>
> > Ben Franchuk - Dawn * 12/24 bit cpu *
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

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