To: Silicon Valley Forth Interest Group <svfig@zork.net>
Thanks , Sam .
I googled -nostdlib .
Thank you , Brad , for appreciating the issue .
Phil
Van Cleave who wrote the APL
68000 1st.CoSy ( 0 origin if you want to
justify 4th.CoSy ) is
built on wrote his assembler first in his Z80 APL and then the
nascent APL68k itself . I remember thinking his code not great APL .
There is no question that writing an assembler in CoSy would not be difficult
. It's all about slicing and dicing and finding and replacing which
I've
pointed out is the most exercised vocabulary in CoSy . Some of the
important mathy stuff beyond basic accounting at the personal level
( which is largely sdfr ) has been left left as known using
K
as a template .
Thus , CoSy , being just a
vocabulary in Forth , can re-close the loop at the APL level .
BobA
| --
On 2020-11-20 14:50, Robert Sexton wrote:
I concluded a few years ago that the system call
interface was the best way to splice forth together with existing
software in other languages. All of my professional forth work takes
place on Cortex-M devices, which have an easy to use system call
interface. This is easier in a bare-metal application.
I've
had lots of success with combining a small layer of C code for machine
initialization with a forth system that does IO via the system call
interface.
Not only that, but for modern architectures
(especially RISC architectures like POWER and RISC-V;
I haven't studied ARM enough to know if this is true
here as well), the output of a C compiler is
isomorphic with what a human can produce. This is no
accident, as the instruction sets for these processors
are specifically optimized for compiler backend
generation, and so very often there is exactly one
correct way to code a sequence of instructions to
achieve some goal. In these micro-architectures,
while C isn't exactly an "assembler" per se (the
compiler still has flexibility in which sequence to
generate), it might as well be one for all intents and
purposes.
Even for traditional CISC architectures, which
now-a-days dynamically translate complex instructions
into sequences of RISC micro-ops in hardware and on
the fly, the instruction sets are now carefully
crafted to benefit automated code generators the
most. Hand-crafted assembly language sequences of
instructions can actually be *slower* than code
generated by a higher-level compiler (not just C, but
others as well, such as ML dialects, Rust, etc).
This is not to suggest that hand-crafted assembly
is entirely obsolete. But, from an economic
point of view, there is little to gain from
hand-crafted assembly programs anymore. If the
hand-crafted result and the automatically generated
result are isomorphic and run in comparable time, the
effort put into assembly language coding doesn't pay
off. And, you lose any benefit of portability
of the code across different processor architectures.
It's a net-loss.
To answer some of Bob's other concerns, a Forth
generated from a C compiler will depend on the C
runtime library only inasmuch as it is used. GForth
makes heavy use of libc features because, well, let's
face it, libc is essentially the standard runtime
environment of early Unix. But, something like eForth
which targets a more tightly constrained runtime
environment might not need it. Remember that C is a
*compiled* language, and is used to write *operating
system kernels*. There is no run-time associated with
it. Excepting the standard C library, it has no
further dependencies. And, even the standard C
library can be omitted if you simply don't use it.
Every linker for the C development stack includes
something like "-nostdlib", which elides it.
On Thu, Nov 19, 2020
at 1:08 PM Robert Sexton <robert@kudra.com>
wrote:
Bootstrapping forth onto a new
architecture is a lot of work. There are C-based
toolchains available for every single device on the
market, and a forth that bootstraps off of C will be
up and going that much faster. Mitch Bradley's
CForth does it that way.
A C compiler is the fastest way from the
processor architecture so a self-extensible
dictionary.
- Robert
On Thu, Nov 19,
2020 at 2:28 PM Bob Armstrong <bob@cosy.com>
wrote:
On 2020-11-13 04:42, Don Golding wrote:
I would love to hear this talk!
Don
I too .
I don't understand this building of Forth upon
some ` higher level legacy language . I'd like
to understand the motivation .
It seems like a failure of Forth to deliver what
is claimed for it -- like the use of Python for
` practical level problems by some of the most
deservedly venerated in the Forth pantheon .
FWIW, I share this worry!
There's a profound increase in complexity the
moment you pull in another tool, especially one with such a
tight set of constraints on the sort of Forth you can build.
The reasons I've intermittently entertained it
mostly are very much about "rendering unto Caesar" so to
speak:
* Running on an OS
- Modern OSes and the libraries tied to them
have complex interfaces, where often the only specification of
the interface and myriad structures passed to it is a
collection of C header files.
- Unix doesn't really offer binary
compatibility, everything is suppose to be from source. That
precludes a bootstrapped EXE or the like, leaving source in
some language like C/Rust or Assembler, but rules out Forth
itself (at least for the core), which is galling. Raw syscalls
are reasonably stable, but you can even have the instruction
set pulled out from under you, e.g. Windows is the only
remaining major OS that deigns to leave in full 32-bit support
on 64-bit machines.
* A semi-irrational dislike of contemporary
assemblers.
- For various reasons I'm frequently on a mix
of Windows/Mac/Linux systems, and while yasm/nasm/gas sort of
fit the bill there isn't really a single tool / format that's
universal. Especially when you want to dynamic link to bunch
of libraries and work with more than one architecture.
- I've dabbled in building ELF binaries etc.
directly, but when you add in all the extra gunk needed for
dynamic linking, the c toolchain starts to look like a
complexity win.
* Bad Tools won
- Handing someone a source file that can be
edited and compiled using for instance the Arduino IDE for
ESP32 makes a Forth built this way accessible. The esp-idf
toolchain is horrendous to install, especially in windows.
While on Linux you can usually just install the compiler
itself, for a board with a Wi-Fi stack, you usually want
libraries and soon even an assembly Forth isn't standalone.
(Though I entertain fantasies of implementing that stack from
scratch).
- Little things like if you want to have an
icon for your EXE are goofily intertwined with OS toolchains.
Clearly the OS is the source if my woes.
I very specifically chose a Forth ( Reva ) built
directly in , and containing , a chip based
assembler ( x86 ) . I want ( require ) the full
stack from processor to APL level to be
open . Having left the legacy language world
for APL just as Pascal was having its brief
honeymoon before UNIX/C domination , I have
never learned those intermediaries .
I'm not clear whether " Forth in C " means
simple a compiler written in C which produces a
Forth running on a specific chip architecture ,
or something that still requires a C layer
underlying the running Forth . If the former is
the case why does Forth fail to be easier to
construct the compiler in than C ? Making cross
compilers with new architectures as target was
one of the early examples ( tho complex ) in
Starting Forth .
So as I'll cover in my talk I do care about the
machine code coming out the other end, so some of the focus is
on making it not too bad. A VM running in C running Forth
definitely isn't the intent.
Mostly the later sadly, as I clearly lack the
conviction to just start from a boot sector and dispense with
the OS.
I would rather be cross compiling, but the
target formats have all gotten dreadfully complex. If only it
was a bare binary blob.
I do sometimes ponder writing just a sort of
loader/linker in C. Perhaps make a nice boundary that exposes
some simple "syscall" layer. Need to think about that path
more...
As with other ` toy Forths built upon languages
which handle dynamic memory management ( tho
they may have their practical uses like Brad's
Javascript ) to me they miss the fundamental
point of Forth as the minimal path from a
processor architecture to a self-extensible
dictionary .
| --
That all being said , I just was in this
morning's British APL Association Zoom where
Dyalog APL was demonstrated in a Jupyter
notebook . I had not realized that such
notebooks can apparently be run as a ` widget
embedded in a webpage with no visible presence
of Python . That appears to perhaps offer the
shortest path to having CoSy
running as a sand-boxed web app .
The browser is another tempting target, but also
a whole world of additional complexity. :-/
But that's the boundary of my understanding .
Beyond that lies my infinite ignorance .
| --
Bob A
| --
On Thu,
Nov 12, 2020 at 10:21 PM Brad Nelson <bnels123@gmail.com>
wrote:
EForth implemented in C
---------------------------------
An exploration of various
approaches to build EForth on top of
C, we'll look at variations on the
core interpreter, how to populate
the dictionary, X-Macros,
alternate memory models, and will
draw comparisons with approaches
taken in cforth and gForth.
