[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] RC5, F-CPU and srotl
----- Original Message -----
From: Yann Guidon <firstname.lastname@example.org>
Sent: Tuesday, April 16, 2002 7:12 PM
Subject: Re: [f-cpu] RC5, F-CPU and srotl
> 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
> 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
> > 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
I'm not speaking about a text interpretor but a code interpretor.
My code is a FORTH code interpretor (when you run your FORTH code) but it seems
to have some error so i will reput it when errors are gone :)
> 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
> 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
ok sorry, i invert the thing
> > I did create a virtual machine, that is, a FORTH-like CPU. That was great
> > 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 ?
when i was in University. I simulate in C a FORTH-like CPU. Not exactly a FORTH
langage but a machine code working with data and code stacks instead of
> i remember when i was 16 : i wanted to make a Forth machine using Turbo
> and it soon became a nightmare. it's certainly easier to do this in F-CPU
> But a "synthesised" Forth code (not just a play with the code entry
> will be much more efficient because it will unwind the data dependencies and
> allocate more registers, jump much less and make parallel things.
Sure, making it for a traditionnal CPU is not the best thing to do ;)
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/