Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!nuts!cc.nu.oz.au!eepjm From: eepjm@cc.nu.oz.au Newsgroups: comp.lang.modula2 Subject: Re: Modula-2 "object" format for def'n module? Message-ID: <3229.27315adb@cc.nu.oz.au> Date: 2 Nov 90 01:39:07 GMT References: <43710@eerie.acsu.Buffalo.EDU> Organization: University of Newcastle Lines: 71 In article , 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.