🚀 go-pugleaf

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

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.

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.

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

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

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