From: dxforth@gmail.com
On 30/09/2024 4:44 am, Paul Rubin wrote:
> dxf writes:
>> Perhaps I misunderstood. So we agree Forth locals are unlikely to
>> ever match C locals for performance?
>
> This I don't know. If the issue is parameter passing in registers,
> maybe a fancy enough Forth compiler could do that.
IMO no because C doesn't have the complication of a permanent parameter
stack. C typically pushes parameters onto the cpu stack which are the
locals, and which the calling function eventually discards. In forth
locals amount to a 2-step process - pushing parameters onto the data stack,
pulling them off as locals and potentially storing them back. Contrary
to what one may imagine this is more costly than 'stack juggling' which
has become a pejorative. Forth has a data stack. It's left to the user
to optimize it, or to abuse it, as he sees fits.
>> I don't know whether it's possible to make forth code using locals as
>> efficient as forth code using stack operations. What I do question is
>> the necessity for it and the wisdom of it.
>
> I think in case of an interpreter, locals might be more efficient, since
> as the thread title says, they treat the stack as an array. The
> hardware is built to do that, so why not use it? With an optimizing
> compiler, I think they should usually be equivalent in principle.
I don't understand the reference to 'interpreter'. Having an interactive
environment with incremental compiler is very convenient but mostly I'm
coding for a target, the same as any C programmer.
> ...
> Do you still use blocks instead of files nowadays?
For applications I've always used files as that's the norm for CP/M
and MS-DOS. ANS-style file functions suit this very well. For forth
source I use files organized as 'screens'. DX-Forth comes with TED -
a regular text editor that can be used within forth - but personally
I prefer screens.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
