darryl@ism780c.UUCP (Darryl Richman) (12/02/86)
I am a neophyte in Modula 2 land, so if these questions are simpleminded, please be patient with me. I have Wirt's PIM2, edition 2 (I can't locate a copy of edition 3). 1) If I build an application with multiple modules, what, if anything, am I guaranteed about each module's initialization code? (I've looked at several books and they either ignore the issue or say contradictory things). In particular, am I guaranteed any particular order of execution? What happens if one module's initialization code bootstraps the application, but other modules haven't had a chance to execute yet? 2) What did Wirt change from edition 2 to 3? In particular, what does he say about NEWPROCESS, TRANSFER, and IOTRANSFER? (My compiler, which is from ETH, does not supply these procedures and implies that they are not required. Instead they have a process stacking paradigm that's not as powerful.) 3) Is it really considered a feature of the language that, given frp is a function returning a pointer, the expression "frp()^.xyz" is not allowed and must be coded as "tempP := frp(); tempP^.xyz"? Thanks very much for any light you can shed! --Darryl Richman, INTERACTIVE Systems Corp. ...!cca!ima!ism780!darryl The views expressed above are my opinions only.
firth@sei.cmu.edu (Robert Firth) (12/03/86)
In article <4740@ism780c.UUCP> darryl@ism780c.UUCP (Darryl Richman) writes: > >I am a neophyte in Modula 2 land, so if these questions are simpleminded, >please be patient with me. I have Wirt's PIM2, edition 2 (I can't locate a >copy of edition 3). > >1) If I build an application with multiple modules, what, if anything, am >I guaranteed about each module's initialization code? (I've looked at >several books and they either ignore the issue or say contradictory things). >In particular, am I guaranteed any particular order of execution? What >happens if one module's initialization code bootstraps the application, but >other modules haven't had a chance to execute yet? [References are to PiM2, Third Edition. Sections are as in the Report bound into the back of that edition] "As in local modules, the body of an implementation module acts as an initialization facility for local objects. Before its execution, the imported modules are initialized in the order in which they are listed. If circular references occur among modules, their order of initialization is not defined" [Sect 14] I interpret this as meaning that, given the dependency graph of the program, the modules are initialized bottom-up, ie an IMPORTed module before any of its importers. >2) What did Wirt change from edition 2 to 3? In particular, what does he >say about NEWPROCESS, TRANSFER, and IOTRANSFER? (My compiler, which is from >ETH, does not supply these procedures and implies that they are not >required. Instead they have a process stacking paradigm that's not as >powerful.) "A new process is created by a call to PROCEDURE NEWPROCESS (P:PROC; A:ADDRESS; n:CARDINAL; VAR p1: ADDRESS) P denotes the procedure which constitutes the process A is the base address of the process' workspace n is the size of the workspace p1 is the result parameter. A new process with P as program and A as workspace of size n is assigned to p1. This process is allocated, but not activated. P must be a parameterless procedure declared at level 0. A transfer of control between two processes is specified by a call to PROCEDURE TRANSFER (VAR p1,p2: ADDRESS) This call suspends the current process, assigns it to p1, and resumes the process designated by p2... ... IOTRANSFER ... should be considered as PDP-11 implementation specific" [Sect 13] What Wirth calls a "process" is evidently a coroutine, and processes should be used as one would use coroutines. However, since Modula procedures can keep internal state (using imported modules), you probably don't need coroutines as well. >3) Is it really considered a feature of the language that, given frp is a >function returning a pointer, the expression "frp()^.xyz" is not allowed and >must be coded as "tempP := frp(); tempP^.xyz"? Yes, it is a feature. The syntax of "assignment" requires a "designator" on the LHS, and the left part of a designator must be a "qualident", which can be only selected, indexed, or dereferenced. Klaus screws up again. > > --Darryl Richman, INTERACTIVE Systems Corp. > ...!cca!ima!ism780!darryl > The views expressed above are my opinions only. Well, my opinion is that, for all its sillies, Modula-2 is the best systems implementation language available, and I wish you well with it. Robert Firth
randy@oresoft.UUCP (Randy Bush) (12/04/86)
In article <4740@ism780c.UUCP> darryl@ism780c.UUCP (Darryl Richman) writes: > >1) If I build an application with multiple modules, what, if anything, am >I guaranteed about each module's initialization code? Importees are initialized before importers. Circular imports are undefined. >3) Is it really considered a feature of the language that, given frp is a >function returning a pointer, the expression "frp()^.xyz" is not allowed and >must be coded as "tempP := frp(); tempP^.xyz"? Yes. Sorry about that.
darryl@ism780c.UUCP (Darryl Richman) (12/07/86)
I just wanted to thank the net community for answering my questions--I have
gotten numerous replies. I have since purchased another book which includes
Wirth's "Revisions and Ammendments to Modula-2" paper. I still can't locate
PIM-2 edition 3 locally, though.
Has anyone else noticed that Wirth's module concept leads to innefficient
systems? As a side note, the compiler I use is from his group at ETH. My
machine doesn't support floating point in hardware, so the module SYSTEM
includes routines for all the needed floating point code. This means that all
programs that I build have a complete floating point interpretter in them,
even though I rarely (not so far) use it. The linker doesn't know whether
some procedures within a given module are used or not, so all of them are
brought into the image. Can the linker know what is needed and what is not?
Of course the answer is to break this into several modules (if only I
could). But my Mac has a builtin ROM with 700 potentially useful routines.
Does the "glue" code to get to each one go into a separate module? This
question is a bit hypothetical since the glue code is almost always very
short or nonexistant, but why should a language, one of whose stated goals
is to support low level work, produce bigger than necessary images?
Please do not misunderstand my questions. I am attracted to the language
because, after 4+ years of "language laywering" C, I find it a welcome
relief that the syntax description fits neatly on 2 pages.
--Darryl Richman, INTERACTIVE Systems Corp.
...!cca!ima\
>-!ism780c!darryl
...!sdcrdcf/
The views expressed above are my opinions only.dan@prairie.UUCP (Daniel M. Frank) (12/08/86)
In article <4808@ism780c.UUCP> darryl@ism780c.UUCP (Darryl Richman) writes: >My >machine doesn't support floating point in hardware, so the module SYSTEM >includes routines for all the needed floating point code. This means that all >programs that I build have a complete floating point interpretter in them, >even though I rarely (not so far) use it. Generally, stuff in module SYSTEM isn't really "there", in the sense that stuff in, e.g., Strings is. SYSTEM is a pseudo-module whose functions are normally implemented directly by the compiler. Thus, either there is nothing to link in, or the linkage decision is made differently than you would expect. -- Dan Frank uucp: ... uwvax!prairie!dan arpa: dan%caseus@spool.wisc.edu
bobc@tikal.UUCP (Bob Campbell) (12/09/86)
In article <371@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: > Generally, stuff in module SYSTEM isn't really "there", in the sense >that stuff in, e.g., Strings is. SYSTEM is a pseudo-module whose functions >are normally implemented directly by the compiler. Thus, either there is >nothing to link in, or the linkage decision is made differently than you >would expect. This would be true but in the case of the 68000, there are several things that the compiler believes that it needs that the machine does not provide, and they include 32 bit divide and multiply, as well as all the 32 bit floating point routines. There are included in a module called "System" not "SYSTEM", which the compiler will import implictly. Bob Campbell Teltone Corporation 18520 - 66th AVE NE P.O. Box 657 Seattle, WA 98155 Kirkland, WA 98033 {amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc
bammi@cwruecmp.UUCP (Jwahar R. Bammi) (12/09/86)
In article <4808@ism780c.UUCP> darryl@ism780c.UUCP (Darryl Richman) writes: > >Has anyone else noticed that Wirth's module concept leads to innefficient >systems? As a side note, the compiler I use is from his group at ETH. My >machine doesn't support floating point in hardware, so the module SYSTEM >includes routines for all the needed floating point code. This means that all >programs that I build have a complete floating point interpretter in them, >even though I rarely (not so far) use it. The linker doesn't know whether >some procedures within a given module are used or not, so all of them are >brought into the image. Can the linker know what is needed and what is not? I don't see the connection between the concept of modules and your problem. Its just your implementation that is inefficient (read bad implementation choice). Take a look at systems like the Apollo Aegis that allows dynamic binding (at run time) of libraries, regardless of the language used. Even if your OS does'nt support dynamic binding a decent linker should only bring in parts of modules that are actually referenced (for example look at the TDI modula system). -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155