Path: ...!news.nobody.at!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: Waldek Hebisch <antispam@fricas.org>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Thu, 12 Sep 2024 21:09:40 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vbvlai$3c7ti$1@paganini.bofh.team>
References: <vab101$3er$1@reader1.panix.com>   <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team> <vbhbbb$1blt4$1@dont-email.me> <vbipp5$24kl5$1@paganini.bofh.team> <vbk0d9$1tajm$1@dont-email.me> <vbkpfc$27l2o$1@paganini.bofh.team> <vbl0rh$21tps$1@dont-email.me> <vblie8$2dpn7$1@paganini.bofh.team> <vbmm9v$2d2pi$1@dont-email.me> <vboij2$2naq1$1@paganini.bofh.team> <vbp8e8$2sv6t$1@dont-email.me>
Injection-Date: Thu, 12 Sep 2024 21:09:40 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3547058"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 4874
Lines: 78

Bart <bc@freeuk.com> wrote:
> On 10/09/2024 05:40, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
> 
>>> I've looked at half a dozen hits for 'forth postpone' and I still don't
>>> understand what it does. Apparently something to do with compiled mode.
>>>
>>> I wouldn't know enough to confidently implement it or use it.
>> 
>> Silly example 1:
>> 
> 
> 
> <snip long article about Forth>
> 
> For a non-advocate of Forth you have a lot to say about it!

Consider the following problem: you have a compiled language and
are mostly statisfied with it.  But you would like to add interpretive
execution.  The point is to reduce executable size, bytecode can
be significantly smaller than machine code.  So, you want small
size of interpreted code, but also resonably fast execution (otherwise
to get decent speed everthing would be compiled to machine code,
which would defeat the purpose).  Since this is supposed to be
space optimization, there should be seamless cooperation between
machine code and interpreted code.  In particular interpreted
functions must be wrapped into machine code so that they are
directly callable and wrapper starts the intepreted.  Something
like this is not hard to implement, but problem/question is
to get low overhead.  Now, concerning Forth, traditional Forth
mixes machine code with threaded code, and threaded code is kind
of interpretation.  So I looked at Fort implementation with intent
of understandig tricks which Forth uses to make this fast and
if the tricks apply in more general setting (it seems that not).

For different reasons I looked at use of stack machines as user
visible computation model.

>>>> To give more background, bare ZX81 had 1kB RAM (including video RAM).
>>>
>>> You must mean /excluding/ surely? Otherwise there wouldn't be much left
>>> from 1KB!
>> 
>> There is not much left.  But there is a trick: boundary between
>> video memory and rest is movable, as you fill other part available
>> screen area shrinks.  It does not take long time to have machine
>> completely filled out with no free space left (and IIRC some
>> small screen area for out of memory message)
> 
> So that meagre 1KB had to be shared?

One point of view is that base ZX81 is much bigger than some other
machines.  It could act as decent programmable calculator (popular
Ti-50 had 50 bytes of program space for users and memory for 8
numbers which is roughly equvalent to another 50 bytes).  If you
are staisfied with small display space, then ZX81 can hold much
more program and data than Ti-50.  And all (not many) ZX81 that I saw in
real use had memory extention.

> The Z80 designs I did (for my own use and when I had a job developing 
> commercial machines) never used used tricks like that**.
> 
> I never had to work within very tight pricing, but I would have 
> considered such a machine unviable other than for experimenting.

ZX81 had another cost-saving trick: the CPU did significant part
of work needed to create image on the screen.  In normal mode
CPU was available to user only when it was not busy creating
image (which IIRC was during vertical retrace).  There was fast
mode, when CPU was devoted to user program and no output appeared
on the screen.

Concerning "unviable", ZX81 could be used as a decent programmable
calculator.  I could imagine specialized application for say data
entry or simple control that could run on base model.  But mainly,
people installed memory extention.

-- 
                              Waldek Hebisch