In article ,
Travis Bemann wrote:
>On 6/20/24 05:10, albert@spenarnc.xs4all.nl wrote:
>> There was a lecture on interpreted control structure in Zeptoforth.
>> That was in the forth2020 conference of april 2024
>> I was surprised. In particular it doesnot work for looping
>> building up the dictionary, e.g.
>>
>> CREATE CRCTable
>> 100 0 DO I 8 0 DO
>> DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
>> LOOP , LOOP
>> This IMO is the most useful application.
>
>The reason for this is that interpreted control structures in zeptoforth
>really are not interpreted at all. Rather, they are treated as saving
>the RAM HERE pointer for later restoration and temporarily putting
>zeptoforth into compilation state, with the HERE pointer pointing into
>RAM, until all the outstanding control structures are closed, where then
>all the newly compiled code is executed and then promptly forgotten and
>the original RAM HERE pointer is restored (and if the HERE pointer
>previously pointed into flash, pointing HERE into flash again).
If you noticed, that was approximately what I do.
It works on gforth, it is pretty portable.
I have not the complication dealing with flash.
>zeptoforth makes no assumptions about the position of the top edge of
>the main task's dictionary because new tasks are allotted from high
>memory down, and if memory were allotted in high memory it would either
>be overwritten by new tasks, or would be permanently lost if a new task
>were created, depending on how exactly this were implemented.
You are talking about tasks, and the option to compile code in each tasks?
I can see that this complicate things.
>
>Travis
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
