Future Plans
PM3
The following items are planned for PM3. Items are listed by
decreasing order of likelyhood of being implemented in the near future.
Help on these items is most appreciated!
- Produce binaries for several platforms at every release through remote
compilation servers. We have LINUXLIBC6 computers readily
accessible.
- Add Spencer's emacs files, m3na, and M3 TXL; if the authors submit
an up to date version with HTML documentation, the inclusion will be
immediate. Remove redundancy between the StubLib in
Pickle and the one in Netobjrt. Check enumerating environment variables
under NT386GNU. A few things need to be fixed in Trestle over win32
(fonts, deallocate some handles). Check if m3_strtod is still required
in m3core/src/Csupport/LINUXLIBC6/dtoa.c, because of conflicts with
strtod in libc.
- Decouple m3ship and m3where from m3templates. Currently m3ship is much
too large needlessly.
- Progressively document all the packages using m3doc. For some packages
a small introductory index.html file linking to public interfaces
is sufficient. For some other packages, the m3totex documentation may be
reused (vbtkit, netobj, stable, anim3D, m3tk).
- For Windows NT, get someone to look for native versions of gcc, gdb and
binutils (avoiding the complexity of cygwin32.dll in the gnu-win32 chain
of tools), to check if m3gdb works on version 19 of gnu-win32, and to add
support for building dynamically linked libraries in the NT386GNU template.
- Duplicate modules in pm3 were detected using a modified
m3browser and removed. Some similar modules still exist and should be
merged, see [duplicates]. A few duplicated procedures
do exist, most notably a few Quicksort.
- M3pp has problems with pragma EXTERNAL with flex/bison. It looks
related to function BufferLexeme in lex_help.h which may depend on
lex/yacc internals.
- Detect reusable components hidden in libraries and programs.
Candidates include FSM, MText. Find a category specialist
for each category to drive this effort and enhance the reusable components.
- Increase the use of generic modules. Text may be used for UNICODE
support through generics based on Char.T versus WChar.T ([0..65535]).
Similarly, geometry could benefit from generics based on Integer.T, Float.T,
Point = ARRAY Axis OF Unit, where Axis is {x,y} for 2D and {x,y,z} for 3D.
This could perhaps lead to anim2D versus anim3D.
- Track the evolution of HTML/XML and extensions for vector graphics.
Evolve m3doc towards using these native features in XML as they appear.
- Document how Modula-3 can be used for real time programming, by using
as little runtime support as possible.
- Check the gamma correction performed by Trestle and Image. If indeed
gamma correction is useful (i.e. X windows does none while Mac and Windows
do some and would thus display different colors for the same RGB values and
bitmaps), find a way to let Image tell Trestle if
something does not need to be gamma corrected instead of doing the work twice.
The gamma correction overhead is indeed only a problem for large bitmaps.
- Build a library for browsing and analysing Modula-3 code, probably
based on m3tk and m3browser. It could be used for computing metrics
for Modula-3 programs, detecting procedure clones, extracting object oriented
design diagrams (OMT/UML), or building an enhanced integrated development
environment.
Peter Klein is working on a Modula-3 development environment and associated
user interface.
See the
report
entitled ``Designing Software with Modula-3'',
it describes a software architecture description language
based on Modula-3.
Klaus Preschern, Carsten Weich, Laszlo Boszormenyi
have made the port of Modula-3 to the PC which includes
a student-friendly development environment.
- Rework the HTML kit and the web packages to provide a single
package for accessing WWW documents.
- Provide a serial port access package.
- Provide a high level Database interface, for both PostgresSQL and
ODBC. Eventually provide a native implementation based on persistent objects
for the same high level interface.
- Add some widgets to trestle/vbtkit like a grid (table/matrix) VBT.
Incorporate modifications for a 3D look for scrollbars, Win32 mode
for the TexteditVBT... Make rotated fonts available from Trestle.
- Find/develop graph layout and display packages. Such functionality
may be available from the GRAS/Progres project. GraphVBT already does
the display part.
- Extend the draw, sharedboard, html2ps, mgkit, visualobliq
or anim3D packages to obtain
a nice structured graphics package. This package, not unlike
Unidraw/Interviews, could be used as a basis for diagram editors,
rich text editors, Web browser widget, user interface builder...
- C to Modula-3 converter, initially for declarations (.h files),
to interface C libraries to Modula-3 programs,
but eventually for complete programs. The initial translation would
convert to equivalent UNSAFE structures but subsequent passes may try to
convert char_star to TEXT and so on.
- Develop a network object activator. Network objects servers would
be started on demand.
- Add some authentication and access control to network objects, probably
along with IPv6.
SRC Modula-3
Here is an unordered list of small and large tasks that should be done,
which used to be kept on Bill Kalsow's desk and whiteboard. But,
since it seems to grow rather than shrink over time, here it
is. If you want to work on any of these tasks, go for it.
Copyright (C) 1992, 1996, Digital Equipment Corporation. All rights reserved.
See the COPYRIGHT for a full description.
Driver
- Atomic update of .m3x files
The .m3x files should be updated atomically. If the files are
damaged, users get terribly confused. Similarly, if an object
file gets produced and the version stamps don't get recorded,
users are deceived.
- Integrate quake.
We should write a Modula-3 version of quake that's callable
as a library routine. Then, it should be integrated with the
rest of the driver (Done in PM3).
The resulting program could persist throughout
a development session. Then, the reading, parsing and evaluation
of m3makefiles could be cached across builds and
the list of source files and configuration data wouldn't be
passed through the file system.
- AST cache policy.
The current driver keeps an in-memory cache of compiled interfaces,
but never flushes entries.
So, it's memory usage grows throughout a build.
This will be unacceptable when the
driver lives across multiple builds.
Front end
- New definition of ADR.
The front end should default to using the new definition
of ADR, where instead of ADDRESS, ADR(x) returns an UNTRACED REF T
when the static type of x is T. The new definition increases
the safety of interfacing with the C world. This feature is
available new with the "-X0@-new_adr@" option, but it should
just be the default. The change will require a few source
changes (m3core, libm3 and ui are already fixed). Ideally,
the new types wouldn't require runtime typecells since NEW
is never called on the new types and TYPECASE isn't applicable
to UNTRACED REFs.
- Scanning floating-point literals.
The front end uses the ancient
Convert interface to convert ascii floating point values
to internal binary form. We should use something like the new
Lex interfaces.
- Floating-point constant folding.
The compiler uses the host's LONGREAL type to represent floating-point
values. Instead, it should provide a faithful emulation of the
target machine's floating point. See m3middle/src/TFloat.m3.
- FIRST/LAST(REAL)
According to the language definition, these should be plus and
minus infinity on IEEE platforms. I am pretty sure that even if the
front end used the right values, it would fail to pass them
precisely to the back end.
- Missing debugger info.
The following things are not passed through to the debugger:
IMPORT A AS B, named scalar constants, the Modula-3
type of procedure return values.
- Unreachable TYPECASE arms.
The compiler should emit a warning for a TYPECASE label T
when an earlier label U is a supertype of T.
- Packed array literals.
The front end doesn't always layout arrays of packed values
correctly. See procedure GenLiteral in
m3front/src/exprs/ArrayExpr.m3.
- Non-regular array literals.
The front end doesn't detect 2-D open array initializers where
the inner array values are of different sizes until it gets
into code generation. It should cleanly report these errors
during type checking.
- Type names to prelinker.
If the front end passed user-sensible names for types back to
the prelinker and they were preserved in the version stamp
files, the prelinker could generate better error messages
for inconsistencies (e.g. missing or repeated revelations)
in the program's types.
- Field packing.
Microsoft C supports a "pack" pragma that apparently overrides
the normal field packing rules for structures. The result is
that the Modula-3 compiler and C compiler disagree about
some field layout. For example, CommDlg.PrintDlg has
a 32-bit integer field that crosses a 32-bit boundary. A fix would
be to define a per-platform parameter that describes the minimum
(as opposed to preferred) alignment required for full-word loads.
Then, BITS FOR could be used to fix up the offending layouts.
- Fingerprints of set literals.
Set literals are not canonicalized before they are fingerprinted.
They should be. See procedure GenFPLiteral in
m3front/src/exprs/SetExpr.m3.
GCC back end
- Stack overflow checking.
The gcc-based back end doesn't check for thread stack overflows.
Whenever a procedure is entered whose stack frame is larger
than the thread stack's guard page (Target.Guard_page_size),
the back end should emit an explicit test for stack overflow.
At the moment the front end doesn't tell the back end size
of the guard page and the back end doesn't know the size
of the stack frame when it begins emitting code for the
procedure.
- Gcc optimizer.
It seems that every time I try using the optimizer I get burned.
The most likely cause is that m3cc/gcc/m3.c is not building
properly decorated trees. Given that there's almost no spec for
well-formed trees, it's going to require intimite knowledge of gcc
or lots of tinkering to find the problems.
- Floating-point opcodes on Alpha.
The Alpha machine description should be modified to generate
floating point opcodes that allow software fixups of denormalized
values. It should also insert trapb instructions where needed.
- Mips-tfile vs. /bin/ld.
On DS3100, the version of mips-tfile in gcc 2.5.7 generates object files
that cannot be linked by /bin/ld. Problems occur when the object
module defines an externally callable procedure and the linker
is asked to generate the procedure table. If this problem was
fixed, we could generate direct procedure calls rather than indirecting
through the interface records.
NT back end
- Return values from external procedures.
Apparently, not all procedures (e.g. NB30.Netbios) return
fully sign-extended results in the return register. I guess the
conservative thing to do is to sign or zero extend all procedure
results from external procedures. (and procedure variables too?)
- DLLs.
We should be able to generate and use DLLs. Unfortunately,
Microsoft requires different code sequences to reference
a global variable (e.g. interface record) from inside and
outside a DLL.
- CodeView symbols.
The hooks in M3ObjFile already exist, we just need to generate
the debugging data for CodeView debuggers.
- A RISC back end.
Somebody should use m3back and m3objfile as
starting points to building another backend for one of the
current RISC processors. It's much faster to compile
directly from M3CG to object file than to go through the
"ASCII IL -> gcc -> ASCII .s -> assembler -> object file"
mess. Once one RISC back end was written it should be pretty
easy to write others. Register handling will be the primary difference
from the NT back end. High quality code is not a goal.
Runtime
- FloatMode and RealFloat interfaces.
Most platforms don't have full implementations of the floating-point
interfaces.
- Floating-point exceptions.
On the DS3100 platform, we attempt to convert floating point traps
into the proper Modula-3 exception. But, the traps are delivered
via a Unix signal so the longjmp that delivers the exception must
cross a signal handler stack frame. The last time I checked we
go a "longjmp botch", so either the jmpbuf is incorrect, or you're
not supposed to be able to jump out of a signal handler.
- NT -gui vs. Stdio.
When a windows subsystem ("-gui") program is started, it's not
given a console. Hence, writes to Stdio.stdout disappear.
libm3/src/os/WIN32/ProcessWin32.m3 should be modified
so that the standard handles are bound to File.Ts that
lazily create consoles. Then, adding print statements to a GUI
program would produce useful output.
- Table pickles.
The generic table package should register pickle specials.
There's no need to pickle a table's internal hash table.
The pickle should just contain a list of name/value pairs.
The resulting pickle would be robust against changes in the
table's hashing function.
- Incremental GC.
Several platforms that are capable of supporting the VM-synchronized,
incremental and generational features of the garbage collector, need
work. For example, ALPHA_OSF should be easy and NT386 should be possible.
- TCP on NT/386
The Unix TCP veneer needs to be ported to use WinSock.
- Error messages on NT
We need to write or find a routine that generates a readable
message from an NT error number. Such a routine must exist.
Debugger
- Expression parsing and evaluation.
The current expression parser and evaluator are woefully inadequate.
For example, they don't handle floating-point literals, TEXT literals,
or most of the built-in operations.
Misc.
- Versioned shared libraries.
There should be a way to provide multiple versions of a shared
library. Operating systems that support shared libraries usually
support some sort of versioning. The problem is to find a
maintainable, portable way to do that in the current Modula-3 and
m3build environment.
- QPT is broken.
Jim Larus' QPT doesn't seem to work with DS3100 binaries. Possibly
the problem is that it doesn't properly translate the exception
tables in the initialized data segment. ??
- M3browser and type uids.
It should be possible to find types by their 32-bit UID
using m3browser.
- Exceptions as return values.
What would it cost in time and space to implement exceptions
as simple return values? Suppose you were allowed to change
the calling convention so that each procedure call site
had two return locations. Then, non-exceptional returns would
cost nothing (except a little code space) and exceptional
returns would be quite fast.
- Modula-3 parser.
There should be a reusable, lightweight Modula-3 parser.
Probably the parser should be easy to hack and lightweight rather
than fully general, extensible, and slow as molasses.
- Validation suite.
The current test package m3tests is a joke. Many
more tests should be included. The m3makefile should be made
to work on NT.
- M3ship warning.
M3ship should warn you if the m3makefile is newer than the
.M3EXPORTS files. Shipping a package after it's m3makefile
has been modified, but before it's been reevaluated, often
leads to confusion or surprise.