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

[Yann Guidon <whygee@f-cpu.org>]

hi !

Christophe wrote:
> I knew FORTH as being in fact a mix of compiled and interpretable code :
forth is always more than one can think of, one reason is because the
coding density is extremely high : the code is both the source and the
executable, it is highly reflective (in a certain way, it codes itself)
and there are a lot of sophisticated techniques that are mixed at every levels.
It gave me some headaches and sleepless nights when i was young and i stayed
with Turbo Pascal instead :-P IIRC, when Forth "compiles" code, it's often a
"condensed" representation of the existing modules, something like :
putting each code module together (copy and paste) and remove the jumps
at the ends, or something like that. The "win" is because the linked list
search is not performed all the time. Today, one would use gperf and
sophisticated hash tables instead...

> 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.
it is certainly faster than looking up all the symbols in the linked lists :-)

> 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:...

i don't understand your asm code. There is probably a misunderstanding with
the jumps : the destination address is the 2nd operand. I see for example
>     if (r61 == 0) jump r0,r55
which means that you jump to the address stored in register zero, which contains zero,
and you save IP+4 to R55. The "trick" to remember is that
 - the condition is at the left
 - the pointers are in the middle
 - the destination is at the right

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

i am not sure to understand the context :-/ Forth is very old to me.
i had a small book about it ("Guide Marabout") but i have lost it more
than 8 years ago...

> 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.

i don't understand (i know i should sleep but you know me :-D)
you did this now, or you have done this in another context ?

i remember when i was 16 : i wanted to make a Forth machine using Turbo Pascal
and it soon became a nightmare. it's certainly easier to do this in F-CPU asm.
But a "synthesised" Forth code (not just a play with the code entry addresses)
will be much more efficient because it will unwind the data dependencies and
allocate more registers, jump much less and make parallel things.

> 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
> ...

This looks ugly, sure.
and i'm not sure it's any thing like efficient.
it will work but be even slower than GCC-generated code ;-P

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