🚀 go-pugleaf

In article <josef.657189394@peun11>, josef@nixdorf.de (Moellers) writes...

>I am currently busy to write my own Modula-2 compiler.
>Although progress is very slow, I would like to know if someone could
>give me any hints on the format of compiled "DEFINITION MODULE"s.
 
In article <43710@eerie.acsu.Buffalo.EDU>, v056ped5@ubvmsd.cc.buffalo.edu
(Brian M McNamara) replies: 

> I may be wrong, but I always thought of DEFINITION MODULE's as a text
> interface to compiled code. If I am wrong would someone drop me a line
> on how exactly you would use a compiled DEF MOD? Also, anyone who uses

I haven't decoded the format used by any of the compilers available at
present, so can't give a PRECISE answer to the first question, but I think
I can clear away some of the confusion.  Here goes ...

How is a definition module used (by the compiler)?  Obviously, when the
compiler hits an IMPORT declaration.  As v056ped appears to have assumed,
one could *in principle* read the definition module at that point, but it
would be unreasonably inefficient (especially if you import from a lot of
modules, which often happens in Modula-2 programming. Now if only somebody
could invent a super-module or module of modules ... but that's another
story).  So in practice we do it this way:

1. User compiles the definition module, and from this the compiler creates
   a "symbol file".  The compiler which I use most of the time (FTL) calls
   this the .LMS file, many others call it the .SYM file.  In any case, it
   is quite distinct from the "object file" which is produced when
   compiling an implementation module.
2. Whenever the compiler hits an IMPORT, it reads in the appropriate
   symbol file and adds the information in it to its internal symbol
   tables.  It's better to read the symbol file rather than the original
   definition module file at this point because:
    (a) The definition module file is full of lots of redundant stuff
        like comments, and it would slow the compiler down to have to
        process all of that again.  The symbol file is the same
        information in a more compact form.
    (b) The compiler designer can, if he/she wishes, design the symbol
        file format so that it is an exact image of the symbol table which
        the compiler is going to want to set up in memory as a result of
        processing the IMPORT declaration.

Point 2(b) is sort of an answer to the original question.  Think of it in
terms of a top-down design: what information is the compiler going to want
to access when it encounters an imported name in, for example, a procedure
call?  That tells you something about how to design the symbol table(s) in
memory.  Once you have that design right, that tells you what you need as
information in the symbol file, and how to format it.  Consequence: actually,
you don't even need to design the symbol file format until you have already
written a lot of your compiler and have reached the point of thinking about
type checking and code generation and things like that.  In my opinion,
this needs-driven approach to design is far superior to the approach most
people seem to use, which is (a) decide on a format for the symbol file;
(b) much later, while writing various parts of the compiler, try to
find ingenious methods for accessing the information held in a
badly-designed symbol file.

One final point: I personally find it easiest to have a separate symbol
table in the compiler for each module imported via the "IMPORT ModuleName"
construct, but to put symbols imported via "FROM ModuleName IMPORT ... "
into the same symbol table as used for global symbols belonging to the
current module.  (Also, you need special treatment for nested modules.)
That way, it's easier to set up the search path when the compiler is
looking for a name.  But that's just a personal opinion, others might
have different ideas.

Hope this helps.

Peter Moylan                           eepjm@cc.nu.oz.au
Dept. Elec. Eng. & Comp. Sci., Univ. of Newcastle, NSW 2308, Australia.