Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]
Date: Mon, 16 Sep 2024 17:37:19 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 66
Message-ID: <2024Sep16.193719@mips.complang.tuwien.ac.at>
References: <nnd$61e0ad9a$48ed61c2@b4d945e456041481> <2024Sep15.181634@mips.complang.tuwien.ac.at> <vc7ju4$2cu8t$1@dont-email.me> <87o74o1thp.fsf@nightsong.com> <vc97od$2r97o$1@dont-email.me>
Injection-Date: Mon, 16 Sep 2024 19:50:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="30716ef6ab1ebd867530a5bb0a7c7e47";
	logging-data="3129219"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cqoQjc77evihNXuaKdNjw"
Cancel-Lock: sha1:SfL61wgG5obf+3kF2nq13cbDLLc=
X-newsreader: xrn 10.11
Bytes: 3190

Stephen Pelc <stephen@vfxforth.com> writes:
>On 15 Sep 2024 at 23:45:22 CEST, "Paul Rubin" <no.email@nospam.invalid> wrote:
>
>> Stephen Pelc <stephen@vfxforth.com> writes:
>>> I would not make that trade off today.
>>> So there's only one Stephen Pelc but two application domains.
>> 
>> I wonder how much effort de-localizing the TCP/IP stack took, compared
>> to hypothetically updating the compiler to optimize locals more.  If the
>> TCP/IP stack code can compile with iForth or lxf, is there a way to
>> compare the code size with VFX's?  I can understand wanting to use VFX
>> for actual delivery, of course.
>
>On modern desktop CPUs, I would probably spend the effort on
>optimising locals more. However, the ability to provide the address
>of a local is essential in our world. I have not inspected our code
>base to see how many uses of a local declaration of a buffer
>: bah   {: ... | FOO[ cell ] ... -- :}
>there are compared to the use of the ADDR (address) operator
>applied to a normally defined local
>: bah   {: ... |   FOO ... -- :}
>...
>  addr FOO

Yes, that's why Gforth does not support ADDR for locals by default:

: bah   {: ... |   FOO ... -- :} 
  ...
  addr foo 
*the terminal*:3:8: error: Unsupported operation
  addr >>>foo<<<

If you want that, there are two options: Either make it explicit with
WA: which local should support ADDR:

: bah   {: ... |   wa: FOO ... -- :} 
  ...
  addr foo 
;

compiles without error.  Alternatively, you can force slow mode on all
locals with DEFAULT-WA:.  So

default-wa:

: bah   {: ... |   FOO ... -- :} 
  ...
  addr foo 
;

compiles without error.

One intermediate option is to warn about ADDR applied to locals
defined without WA: FA: DA: CA:.  Once the program compiles without
any of these warnings, you can set

DEFAULT-W:

to gain the full speed for all the other locals.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
   EuroForth 2024: https://euro.theforth.net