Vedran has quit [Quit: Ping timeout (120 seconds)]
dave0 has joined #forth
Vedran has joined #forth
<neuro_sys>
I was thinking about it today, I think to write "re-entrant" code (although this is not a necessity most of the time), pick and roll is a necessity to allow parameter referencing deep in the stack.
<veltas>
neuro_sys: On most forths the stack is at least mostly addressable using e.g. s', s0 is the base
<veltas>
But ... I can't think of a reason why you need to access stack during an interrupt (if that's what you mean), only what's in the current interrupt / stack.
<neuro_sys>
MrMobius: Sorry I actually meant thread safe.
<neuro_sys>
Or more clearly, I meant not using fixed memory locations for the program, so that it can be executed simultaneously by different tasks/processes.
<neuro_sys>
But I'm wondering if Forth systems handle multitasking so that dictionaries are private to each task, then it is safe to use dictionary for data access and it would be still thread safe.
Vedran has quit [Ping timeout: 256 seconds]
Vedran has joined #forth
hosewiejacke has quit [Ping timeout: 272 seconds]
marksmith has joined #forth
hosewiejacke has joined #forth
dave0 has quit [Read error: Connection reset by peer]
<veltas>
neuro_sys: PolyForth does this, and other forths. They have 'user' variables and user dictionaries local to a thread, and a system dictionary/variable for some stuff (e.g. words common to all threads)
dave0 has joined #forth
<veltas>
I believe e.g. gforth has support for this
marksmith has quit [Ping timeout: 246 seconds]
dave0 has quit [Read error: Connection reset by peer]
<MrMobius>
veltas, wouldnt anything you do in an interrupt access the stack if the interrupt's in forth?
marksmith has joined #forth
<veltas>
I mean an interrupt shouldn't interfere with the current stack contents or expect anything particular on the stack
<veltas>
I think I misunderstood what particular problem neuro_sys was trying to solve
<veltas>
I understand now they are trying to make all their state 'automatic' or 'stacked' so it can be used arbitrarily without thought for where it's currently running
<veltas>
neuro_sys: rdrop-exit or someone I can't remember implemented this by putting stuff in the pad area, and allowing increasing and decreasing the size of the pad with pad+ and pad- by 256 bytes or something
<veltas>
Their pad was at the end of dictionary space (rather than just after HERE) and so it could grow downwards like a stack
<veltas>
So at the start of a word they could pad- to get some more reentrant space if they wanted, and then pad+ to clean up
<veltas>
The other (more common, but not as general-purpose) trick is to just ALLOT space and then ALLOT with negative argument later
<veltas>
Obviously that has limitations on where it can be used, but in forth that should bug you less: YAGNI to the extreme etc
<veltas>
I'm currently writing a merge sort algorithm that uses this space for the merge buffer.
<veltas>
And then it's convenient too because you can ALIGN and then use , to write to it like a stream
marksmith has quit [Ping timeout: 264 seconds]
<neuro_sys>
Yes, I didn't mean reentrancy (misused the term), and I don't see any problems with interrupts wrt Forth (actually it's faster since there's no register saving/restoring).
<neuro_sys>
On another note, I changed my forth lib words to use Dictionary instead. Now I'm focusing on the classic style, and not using local variables, and reading more material.