Re: Top 10 most common hard skills listed on resumes...

Bart <bc@freeuk.com> wrote:

On 09/09/2024 02:19, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

On 08/09/2024 19:13, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

On 08/09/2024 01:05, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

>

Then you no longer have a language which can be implemented in a few KB.
You might as well use a real with with proper data types, and not have
the stack exposed in the language. Forth code can be very cryptic
because of that.

>
First, it is not my goal to advocate for Forth use.

>
You're doing a fine job of it!
>
For me it's one of those languages, like Brainf*ck, which is trivial to
implement (I've done both), but next to impossible to code in.

>
I wonder if you really implemented Forth.  Did you implement immediate
words? POSTPONE?

>
I implemented a toy version, with 35 predefined words, that was enough
to implement Fizz Buzz. Then I looked for more examples to try and found
they all assumed slightly different sets of built-ins.

 
OK, so apparently you missed essential part.

 
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:

: mark 9876 . ;

: imark mark ; IMMEDIATE

: baz imark ;

Comments: 'mark' simply prints easily distinguishable message (number).
Due to 'IMMEDIATE' after 'imark' it is executed at compile time,
that is when Forh compiler sees 'imark' is suspends compilation
of 'baz' and starts execution of 'imark' which prints message
_at compile time_.  Since 'baz' contains no other code nothing
interesting happens when we run 'baz'.

Silly example 2 (with the same 'mark' as above):

: pmark POSTPONE mark ; IMMEDIATE

: bar pmark ;

Comments: Here, due to 'IMMEDIATE' 'pmark' is executed during
compilation of 'bar'.  So "POSTPONE mark" is executed.  Due to
'POSTPONE' instead of execiting 'mark' Forth compiler adds call
to 'mark' to the compiled code for 'bar'.  So final effect is
that executing 'bar' executes 'mark' that is prints the message.

Above were silly examples, but point is that say 'pmark' could
do arbitrary computation and depending on result of this computation
call POSTPONE or not.  'pmark' could use 'POSPONE' many time and
generate a lot of code.  'pmark' can read program text following
it and base its decisions on what it has seen.  So, for example
you could define word calles say 'infix'.  Such work would read
program text following it up to some end marker.  It could
parse it using infix syntax and use 'POSTPONE' to generate
corresponding code.

Another mysterious feature with hard to understand semantics. You did
say this was a very simple language and trivial to implement in a few KB?

Yes, it is very simple to implement.  First, several parts of Forth
compiler are exposed as user routines, some are actually useful
for "normal" programs, but some are intended as a tool to create
extentions, if you think about them as "ordinary" routines they
make no sense.  Once you understand the purpose, they are sensible.

Next, base structure (you probably know this, but just in case).
There is dictionary holding defined Forth words.  Simple linked
list will do.  Definition has name, few flags and associated
data/code.  Simplest Forth may keep data inside dictionary.
Alternatively, you have separate data area and in dictionary
entry you store pointer to the data.  You need routine to find
definition in the dictinary.  This routne takes name (string)
as an argument and returns say pointer to dictionary entry.
A simple variant of this routine is exposed as user procedure
FIND.  Half of work of POSTPONE is done by this routine.
You need a few routines that create dictionary entries, that
is ':', 'CONSTANT', 'VARIABLE', 'CREATE', etc.  They require
extra things, so fully can by only defined later.  But
they have common part which creates "header", that is puts
name, flags and link in the dictionary.  Routnes creating
dictionary entries differ in which flag they set and mainly
which data they store.  Once you have basic Forth machinery
in place you can do rest as an extention as Forth code.
But to get started you need a number of words, I do not know
how many.  You may look into Forth standard, there is something
like 130 "core" words and probably to be able to do rest in
Forth you will need about 30 other words.  Depending how
you structure you implementation you may be able to define
some core words in Forth.  Anyway, before Forth is operational
you need a way to fill say 100 dictionary entries.  Hardcore
Forthers would create inital dictionary as an assembly definition
(use assembly directives to create data structure).  You may
use your languaage to create appropriate data structure.

Crating "haders" is easy in any HLL, but of course you need also
data/code.  Here there are primitives that traditinally are
short pieces of machine code.  You probably need 30-40 of them,
things like '+', stack manipulations (remeber, there are two
stacks so that increases number of needed operations).  In
corresponding dictionary entries you store addresses of primitives.

Next, execution engine.  Simplest Forth implementation
is based on threaded code, execution engine is few machine instructions
(exact count will depend in details).  It used few machine
registers which are supposed to have fixed meaning during
execution of forth words.  Each "Forth" definition
contains a stub that transfers contol to execution engine,
Code in execution engine saves info about previous routine
and then stars executing current one.  Maybe I will not go
into details here, there few subtly different schemes in
use, they are described in the net.  As I wrote it is few
machine instructions, but if you deviate from known schemes
you may end up with something non working or much more
complicated then needed.  Anyway, code for each Forth definition
has inital stub and sequence of address.  Final address is
addres of routine that return control to the caller.  Actually
the, there is a little twist there and return and exection
of caller are merged.  But the point is that there is fixed
start and fixed end and real work of the compiler is to fill
the middle with addresses of corresponding words.  Concerning
POSTPONE, at compile time of definition containing POSTONE
it reads following name, find definition in the dictionary
and stores corresponmding address in its body.  When code
of POSTPONE is executed, it simply stores address contained
in the body of POSTPONE into currently compiled definition.

Remark: there is dozen or two global variable playing important
role in Forth.  In particular there is thing called HERE
which notes position of currently defined data.  So this
"store into definition" reads global variable, and uses
result as address of target of store.  Then it bumps this
variable to move to next machine word (Forth data is usually
stored as whole words).

Now about compiler: compiler read string (name of word)
from input buffer, advances input and looks for the name
in the dictionary.  In name is the dictionary it looks at
flags.  If the word is in the dictionary and has "IMMEDIATE" flag,
then compiler switches to execution mode (called "interpretation
state" in the Forth standard) and calls corresponding code.
If the word is in the dictionary and but does not have
"IMMEDIATE" flag, then correspondig address is stored in
the current definition.  Otherwise compiler tries to recognize
a number, the string is a number than it generate corresponding
code, that is stores address of a helper routine and after
it stores the number.  At runtime helper routine uses info
from register to know location in the code and fetches
the number (and of course puts result on the stack).
There is a little issue here, compiler must avoid executing
incomplete definition and also normally does not do recursive
calls (intead calls previous definition).  So there is a flag
to mark incomple definitions and special source construct to
set a flag indicating that current definition is recursive.
But that is almost all compiler.  Similar thing is done
to implement command line and interpretive evaluation,
but this interpretive mode is executing words instead of
storing them in the definition.  So compiler an interpeter
can share most of code and just use a flag to distinguish
mode.

That may look suspicious, as I did not write anything about
control structures.  Well, contol structures are implemented
by IMMEDIATE words, they plant calls to helper routines that
do conditional and uncoditional jumps.  Funky look of Forth
control structures is related to fact that corresponding words
have very simple job to do, they either store info about start
of a structure, plant jump or both.  At finish of a control
structure there may be need for backpatching, that is filling
address of already planted jump.  Part of info needed for this
is stored during compilation on Forth stack.

In traditional Forth user routines could plant addresses of
helper routines used by control structures.  Standard Forth
defined this in abstract way, so it works also if you generate
machine code instead of threaded code.  Point is that machinery
to compile contol structures is available to users.

Coming back to "simple to implement": several Forth words
essentially expose internals.  If you have "wrong" internals,
then those words will not work as expected.  If you have
no idea how Forth is implemented, then it can be quite
hard to discover right pattern.  But this is described in
books and articles on the net.  There is 'JohnesForth'
which is 2314 lines of i386 assembly and 1788 lines of Forth.
Most of assebly in JohnesForth is to fill inital dictionary,
if you use different language to fill dictionary then amount
of assembler can be dramatically lowered.  And BTW, line count
above includes _a lot_ of comments.  There is assembly
source of FIG-Forth (JonesForth has very similar structure,
but is for 32-bit mode).

Forth standard says you what various things are supposed to do,
there are comment/rationalle parts which say how things _may_
be implemented, but thiose are just samples.  And it may be
hard to connect abstract sounding terminalogy with practice.
Still, standard say you what words are expected in modern Forth
and for "ordinary" words descriptions are reasonably readable.

My opinion of Forth has gone down a couple of notches; sorry.

Well, implementing real programming language is a real job.
There is some fun in implementing things, but as I mentioned,
on modern machines one can get more advantages than Forth from
different languages (at cost of more machine resources).

And to be clear, you do not need explicit stack to get main
advantages:
- interactivity: that is possiblity to add code at runtime,
  kinda trivial in interprters (if you do not mind slowdown),
  but if symbol table is part of runtime than compiler invoked
  from inteactive command line can compile single routine to memory,
  register it in symbol table and pass control back to interactive
  toplevel.  That is how Pop11, Lisp, SML typically works.
- extensibility: you need a way to represent code so that
  user-genrated code can be compiled.  One way it to use base
  language as representaiton and implement transformation of
  code, that is how Lisp macros work (I think Seed7 too).  Or
  you can expose code generator in machine indepented way (Pop11,
  Forth).  Or you bet that "everything" can be be expressed
  adequatly within language.  Haskell bets that lazy evaluation
  and use of functions after optimization give effect of code
  transformations.  OO crowd bets that inheritance and smart
  exception handling will do (in Smalltalk officially everthing
  is a method calls, when you call non-existent method, it
  goes to exception hander that can do now things).  I think
  that previous approaches are more powerfull, both Lisp and
  Pop11 implement advanced object systems as a "user extention",
  but OO folks think that they have enough fun.
- small size of obect code: byte code is usually smaller than
  traditional Forh threaded code (on big macines much smaller,
  but also smaller in 16-bit ones), but executes more slowly
  that Forh threaded code
- speed of object code: compiler generting machine code usually
  give faster code than Forh threaded code.  If Forth generates
  machine code, then whoever spent more work on optimizers
  wins.  In fact, small project has hard time to competes with
  gcc and clang (but Ocaml did present interesting benchmark
  figures).  Machine code is bigger, but old trick is to
  optimize only small critical part for speed, the rest may be
  unoptimized or say optimized for size by compiling to bytecode.

(I'm not against all stack-based user-languages; I was quite impressed
by PostScript for example. But then I didn't have to do much in-depth
coding in it.)
 

On ZX81? I can imagine it being hard! (Someone wanted me to do something
on ZX80, but I turned it down. I considered it too much of a toy.)

 
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)

The first Z80 machine I /made/ had 0.25KB RAM, to which I added 1KB
(actually 1K 6-bit words; two bits unpopulated to save £6), of text-mode
video memory.
 
The second version had 32KB RAM, the same 1K text-mode memory, and 8KB
graphics-mode video memory. I was able to write my first compiler on
that one, written using an assembler, which itself was written via a hex
editor, and that was written in actual binary. ('Full-stack')
 
But both only had tape storage so tools were memory-based.

I wonder, did you have any ROM?  Or battery backed RAM?  Otherwise
how tape reading worked?  In micros I know about tape reading
was via software, on Spectum this was more than 100 bytes.
It would be rather tedious to key in tape loader via console switches.
Old mainframes had I/O in hardware, but that was rather large
circuitry.

--
                              Waldek Hebisch