File:  [gforth] / gforth / ToDo
Revision 1.5: download - view: text, annotated - select for diffs
Mon Mar 20 18:16:20 1995 UTC (24 years, 6 months ago) by anton
Branches: MAIN
CVS tags: HEAD
added make targets bindist and binonlydist
configure now checks the cell size and chooses the image accordingly

-*- outline -*-

This file describes all the things left to do on GNU Forth. The list
is not complete, so you should add topics you miss or refine existing
topics. If you are working on a topic, add your name to the right of
the topic. If you have completed the work, remove the topic.

This an emacs outline. Use '*' to create topics.

*The Engine
**measure the effect of some variations on different machines:
direct/indirect, NEXT splitting, keeping the TOSses in variables
**make it easy to put the right variation for each processor into the
configuration. I.e., on installation all combinations of options
should be measured and the fastest chosen. Knowing OS and architecture
is not enough, the best options depend more on the processor and the
compiler version.

* ANSI Forth
Add the remaining words

*Run-time System
**Gender-independent image file format and loader
**Stack Checking using the MMU where the OS makes it possible.

*Porting/Portability
** Machines/OSs
VMS (VAX,AXP)
DOS 8088 (16-bit or 32-bit? Note: there are no far pointers in gforth,
so 16-bit means 64k max.)
Windows
OS/2
Mac
Atari
Amiga
Use gcc-generated assembly on machines without gcc, but with
processors supported by gcc

*Foreign Language Interface
If anybody wants to do this, take a look at
ftp://ftp.complang.tuwien.ac.at/pub/forth/foreign.ds
Some of the problems are discussed there,
**C
Stuart Ramsden is doing a bit here.
**FORTRAN
**C++

*Windows and Graphics
**Ask Brian Dunn and Mike Hore for their OS-independent interface
**use the Foreign Language Interface to make X-Windows support

*Program Development Environment
Issues: Convenience, portability across plattforms, compatibility with
existing tools (Emacs, F-PC)
** Decompiler and Debugger
need debugging
** Profiling
The way this (and perhaps also debugging features) could work is this:
On compilation all code fields are remembered somewhere (using a
special hook like etags). If the user now decides to profile part of
the code, the corresponding code fields are replaced by fields
pointing to code that performs the measurement (or whatever else is
intended).
** emacs support
can be improved
**prefix file generator
A tool for generating a prefix file for a program that explains in
what way the program conforms to ANSI (i.e., which wordsets are used)
and contains Forth definitions for the simple non-ANSI words.
** rightcase
A tool that converts all uses of words in a source text to the exact
case of the definition. There's something like this out there on the
net (Joerg Plewe has posted a reference), but I think a program that
wires itself into the compiler (like etags.fs) is harder to fool by
search order tricks etc.

*Object-Oriented Extensions
John Hayes has a portable package

*Documentation
A texinfo file
**glossaries of all wordsets.
*** Inclusion of stack comments, glossary comments, and wordset comments
in all source files.

* Distribution and Announcements
** add copyright notices to all the source files
** Write articles for (general-purpose) magazines

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>