Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!sdd.hp.com!apollo!apollo.hp.com!kumorek
From: kumorek@apollo.HP.COM (James Kumorek)
Newsgroups: comp.sys.apollo
Subject: Re: The wonderful Pascal compilier...
Message-ID: <4e00f26a.20b6d@apollo.HP.COM>
Date: 14 Nov 90 15:32:00 GMT
References: <43023@cci632.UUCP>
Sender: root@apollo.HP.COM
Reply-To: kumorek@apollo.HP.COM (James Kumorek)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 70

In article <43023@cci632.UUCP>, mth@cci632.UUCP (Michael Hickman) writes:
|> 
|> I have upgraded all of our machines to 10.3.  Last night a user tried
running
|> a program I had written that generates a cross reference list of nets
on a PCB. 
|> 
|> After the program ran all night (should have taken < 15 mins.) I killed it
|> figuring it needed to be recompiled under 10.3.  The program compiled fine,
|> but when I ran it, it barfed with an 'reference to illegal address (OS/MST 
|> manager)' on this:
|> 
|>     while not((this_net = nil) or 
|>               ((this_net^.plusminus = net.plusminus) and
|>                (this_net^.net_name  = net.net_name))) do
|> 
|> Looks like it tried evaluating the expression after the 'or' when the
pointer 
|> was nil.  I changed it to this:
|> 
|>     while ((this_net <> nil) and 
|>        not((this_net^.plusminus = net.plusminus) and 
|>            (this_net^.net_name  = net.net_name))) do
|> 
|> It liked this, and the program ran.  However, another function that
uses the EXACT
|> same line as example #1 above works fine with no changes.  Compilier
optimization
|> level made no difference.
|> 
|> It bothers me that it worked fine before, but doesn't now.  I'm
certainly no programming
|> guru, so if anyone can shed some light on this, please do. 
Otherwise, this is just
|> another example of Apollo's great compilier technology.....

I don't think that Pascal defines the order in which a logical expression
is evaluated (unlike C, which defines the order to be from left to
right).  Thus,
in the code 'if (foo_ptr <> nil) and (foo_ptr^.boolean_value) then...', if the
compiler descides that it is more efficient to generate code for the
second part 
of the logical expression first, then that's what it will do.  Note that the
optimiser changes from compiler release to compiler release, so that it may put
out code in different orders from earlier releases.

In order to get around this deficiency in the Pascal language, Apollo
defined the
operators 'AND THEN' and 'OR ELSE'.  These operators ensure that the
evaluation order
is from left to right.  Thus, to recode my little example:

    if (foo_ptr <> nil) and then (foo_ptr^.boolean_value) then ...

One could argue that the compiler could have been smart enough to realize that
other parts of the expression were dereferencing the pointer that is
being checked
in the first part of the expression;  however, there are probably lots of less
'ovious' cases where this would be difficult.  Also, the more checks
that the compiler
tries to do against 'incorrect' uses of language 'features', the slower
the compiler
will be, and I suspect the last thing our customers want is even slower
compilers! :->

Hope this helps....

Jim Kumorek
Apollo Computer, Inc. - A subsidiary of Hewlett Packard
kumorek@apollo.hp.com