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

[Juergen Goeritz <goeritz@oekomm.de>]

Hi,

interesting thoughts. I would be interested in a parallel 
(multi-threaded) forth version or another threaded like
language with a fast execution engine that uses more
compact code than normally and runs multi-threads with
low overhead on a single machine in hardware. And if
the compiler could make best use of the registers to
give each thread a max of performance... 
Why ain't there any multi-thread processor-pool SOCs
around?

JG


On Tue, 16 Apr 2002, Christophe wrote:
>----- Original Message -----
>From: Yann Guidon <whygee@f-cpu.org>
>To: <f-cpu@seul.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
>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
>:-)
>
>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
>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
>>
>
>ok sorry, i invert the thing
>
>> > 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 ?
>
>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
>registers...
>
>> 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.
>
>Sure, making it for a traditionnal CPU is not the best thing to do ;)
>
>
>
>*************************************************************
>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/