muller@src.dec.com (Eric Muller) (01/19/91)
SRC Modula-3 1.6 beta is now available via anonymous ftp on
gatekeeper.dec.com, in pub/DEC/Modula-3. The contents of that
directory has been reorganized:
% ls -R
README m3-1.5 report
comp.lang.modula3 m3-1.6beta
comp.lang.modula3:
README aug90.Z dec90.Z jan90.Z jun90.Z may90.Z oct90.Z
apr90.Z dec89.Z feb90.Z jul90.Z mar90.Z nov90.Z sep90.Z
m3-1.5:
README m3-1.5.tar.Z-03 m3-1.5.tar.Z-07 m3-1.5.tar.Z-11
m3-1.5.tar.Z m3-1.5.tar.Z-04 m3-1.5.tar.Z-08 m3-1.5.tar.Z-12
m3-1.5.tar.Z-01 m3-1.5.tar.Z-05 m3-1.5.tar.Z-09
m3-1.5.tar.Z-02 m3-1.5.tar.Z-06 m3-1.5.tar.Z-10
m3-1.6beta:
dist-1.6beta.tar.Z
report:
README Report.ps Report1.ps Report2.ps Report3.ps
This release is intended only for those that are ready to invest some
time and effort in fixing and testing the release. If you want a "no
problems" installation, you should wait for the release of 1.6. The
rest of this message tells you about some of the problems you may
expect and what you can do to help us get 1.6 ready.
First, thanks for your help. Unfortunately we have access only to VAX
and DECstations; this limits severely our ability to test the system.
This is why your help is very important to get SRC Modula-3 running on
other machines and we appreciate it a lot.
Second, there are still some glitches for the VAX and DECstations. I
decided to go ahead anyway so that we can get 1.6 faster. Here
are the known problems:
- in both versions, there is a glitch in the construction of the yacc
parser for m3pp. Part of the trouble is that we need a
larger-than-normal yacc; normally, we process the yacc file and give
the result, but the construction process wants to build it again.
- in both versions, the Imakefiles for the tests use the "-g" option.
This is option is no longer supported by "m3", as different C compiler
have different syntaxes for the debugging/optimization. Instead, one
should use something like -X1-g or -X1-g3. I'd like to hear about
what the best thing to do is: is the current situation the right
solution or should be have an entry in the config file that indicate
with options should be passed to cc when -g is given to m3 ? or
- in the VAX version, thread switching is broken, but does not prevent
the execution of non-threaded programs (such as the compiler itself).
- in the AP3000 version, thread switching is broken. It is a bit worse
than in the VAX case, in that it probably prevents linking of
Modula-3 programs, but I believe that the basic machinery is sound.
Of course, I am fixing the problems for VAX and DECstations.
Third, this release fixes the alignment problems. However, this means
that the C code generated is much more sensitive to the size,
alignment and structure layout parameters present in
system/compiler/misc/Target.i3.<system>. I hope we got these and
structure layout algorithm (in system/compiler/types/RecordType.m3)
right. If it is not the case for the architecture you are testing and
you don't have 1.5 running, there is little you can do, as it is next
to impossible to edit all the .{i,m}c files by hand; the best in
that case is that you tell me the right numbers/algorithm and I
regenerate the .{i,m}c files. If you have 1.5 running, you can use it
to recompile 1.6beta from the .{i,m}3. By the way, 1.5 can compile
1.6beta, it is actually the version I am using to compile the
cross-compilers that produced the .{i,m}c of the release.
Fourth, the driver has been completely rewritten so that we can support
shared libraries. However, there is still a fair amount of work to
actually have shared Modula-3 libraries (Ultrix does not have shared
libraries and anyway the mechanism depends on the architecture).
Please send the messages about problems/modifications to
m3-request@src.dec.com. I will summarize to comp.lang.modula3 as we go
along.