To-Do List
Here is an unordered list of small and large tasks that should be done.
The list 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.
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. 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.
(Given a quake configuration file, how do we bootstrap such a 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.
- Linker to M3CG.
The current prelinker (m3linker/src/MxGen.m3) generates a C file
containing the list of modules in a program and it's "main" entry point.
Now that the front-end and prelinker are in the same process, the
prelinker should just use M3CG directly. Then, vanilla program building
wouldn't require a C compiler.
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
- GDB version tracking.
The debugger should be upgraded to the latest release of GDB.
The problem is that the Modula-3 support gets smeared around
in several parts of GDB, so upgrading is error prone and tedious.
- 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. ??
- Quake bootstrap.
During the bootstrap process, quake should be built with the
C compiler and options specified in the configuration file.
The problem is that the configuration file is a quake program...
- 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.
[Modula-3 home page]
m3-request@src.dec.com
Last modified on Thu Jan 4 13:22:21 PST 1996 by heydon
modified on Fri Jan 27 10:39:10 PST 1995 by kalsow
Copyright (C) 1992, 1996, Digital Equipment Corporation. All rights reserved.
See the COPYRIGHT for a full description.