milne%icse.UCI.EDU@ICSE.UCI.EDU (Alastair Milne) (06/30/87)
To any experts in MicroSoft Pascal, C, and LINK:
I am a project manager for a U.C. project that creates educational
programs on micro's. For the last 5 years or more, we have been using the
UCSD p-System. But for our most recent project, we have been obliged to
use MS-DOS 3.1 (Japanese) on the Fujitsu FM-16Beta (Intel 80286). With
this, we are using MicroSoft Pascal (for all top- and mid-level routines)
and MicroSoft C (for device-level support). MicroSoft Pascal 3.31
was chosen primarily because it supplies a UNIT compilation module
syntactically similar to that of UCSD Pascal, supplying the same sort
of global, but private, referencing environment. For this reason,
dialects like Turbo Pascal, which has no such ability, didn't seem feasible.
We are having a severe problem that didn't apply under the p-System,
so we have never had to solve it before:
- The code generated by MSPascal and MSC is huge.
- Our largest single UNIT, approximately 4000 lines of Pascal, is used
by every one of our programs. It compiles to about 16K of p-code under
UCSD. With MSPascal, the .OBJ file is almost 64K. I was well aware
that the native code would be larger than the p-code, but 4 times
is much more than I expected. Does 64K of code for 4000 lines
of Pascal sound reasonable to experienced MSPascal users?
- Each program uses 6 or 7 units. The one mentioned above is easily the
largest. Of the others, 2 are fewer than 500 lines, and none is over
1500. They are mostly Pascal, but a couple of them have perhaps 200
lines of C each. Each program itself is from 1500 to 2500 lines
of Pascal. The linked EXE files are between 160K and 200K. This
seems to me an incredible size, larger than PAS1 and PAS2 of the
MSPascal compiler put together.
I have tried EXE2BIN, to see if the code files could be converted
to smaller .COM files. EXE2BIN rejected the files as too big.
Does anybody know if the MicroSoft linker (LINK, ver 3.51) is simply
copying entire pieces of library in, rather than resolving references to
individual units and routines?
Are we causing massive redundancy of support routines by mixing MSPascal
and MSC? If so, I'll be happy enough to turn most of the C source into
Pascal, and the remainder into assembly. However, we declare as
EXTERNs a few C routines to generate random numbers, and to chain to
other programs.
Do EXE files contain global data frames, or stack or heap space
within them? (We need at least an 8K stack to run.)
How efficiently does MSPascal store case tables, floating-point
constants, strings, and other structured constants?
- to try to reduce some of the redundancy of code on the disc (since every
program must contain its own complete copy of the code it uses from the
library), we have considered the possibility of making an entire chain
of programs into a single program, with the formerly separate programs
as UNITs within it, linked as overlays. But this presents another
problem. We must be able to abort cleanly any of the programs, at
any point within them. However, while we can easily enough abort
a whole program with ENDXQQ, aborting a specific scoping level
doesn't appear to be possible.
- Alternately, if we could keep the programs separate, but have only one
of them containing the library routines, we could both reduce
redundancy and exit easily from the individual programs. The problem
then is: how to produce EXE or COM files from OBJ files without
linking in all the libraries, and how to get them loaded and running,
using segments that have already been loaded when another program
was executed? Does anybody know if such a thing is possible?
If further detail is needed on any of these points, I'll do my best to
oblige.
I am also open to suggestions of other languages whose syntax includes
modules: Modula-2 and Ada are two that spring immediately to mind,
though I doubt very much whether there's a respectable, reliable Ada
for the FM-16.
Thanks in advance for any assistance.
Alastair Milne,
Project Manager,
Educational Technology Center,
U. of Calif., Irvine