Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: XFCN/XCMD string in LSC C v3.0
Keywords: A4-relative data, blessing or curse?
Message-ID: <6944@hoptoad.uucp>
Date: 9 Apr 89 10:27:52 GMT
References: <kYDWlFy00VQE8JCEES@andrew.cmu.edu> <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 55

In article <12968@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle
R. Horton) writes:
>     Several problems exist with this approach.  The chief one is
>writing to the code resource.  This is bad.  It can lead to strange
>bugs on 68020 machines.

Sorry, Earle, you're generally one of the better informed voices here
and one well worth reading, but you seem to be having a bad luck streak
this week.  There would only be a problem if the address where A4 is
stashed were executed.  That's the only way the address could find
its way into the instruction cache and cause problems: by being executed.
Since it's just being handled as data, there's no problem.

>     There are places where stand-alone code resources can implement
>"global" variables, and not risk problems with processor caches.
>Inside of the resource containing the code is not one of them.

The processor doesn't know resources from racehorses.  What it knows is
that there are lots of numbered memory locations, and it's ordered to
execute some of them.  These it may cache.  Others it won't, at least
not in the instruction cache.  Stashing data in code space is *not*
self-modifying code.

>Sure, passing a
>pointer to a data structure to every call may not be elegant, but it
>is the only method which I can think of that:
>
>     a)  Works for every conceivable application.
>     b)  Does not write to the code resource sooner or later.

Here we're pretty much in agreement.  In fact, I think it *is* elegant
to keep passing data structure handles through most levels of your
code, though if a routine only uses one or two fields of the data
structure, it's better just to pass those fields.  I've seen too many
programs ruined by indiscriminate use of globals, and I think data
structure arguments lead to far cleaner code in the long run.  However,
I still have not been able to write a serious program with no globals
at all (though I'd think you could do it in a small code chunk like an
XCMD) and mucking about with globals registers remains a neccessary
evil in the real world.  Globals should be minimized as a matter of
good programming practice, but it's unrealistic to expect them to
vanish altogether from any large piece of code.

One more note.  This whole thing got started because of a discussion of
string constants.  Uh, guys, you're not supposed to be using those on
the Mac, ya know.  Sure it would be nice if every compiler let you put
them in code space, but for internationalization, you're supposed to
put all of them into 'STR ' and 'STR#' resources.  I have not found
this to be a real burden as long as you run MultiFinder; you can use
ResEdit while your development system stays up.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Something was badly amiss with the spiritual life of the planet, thought
 Gibreel Farishta.  Too many demons inside people claiming to believe in
 God." -- Salman Rushdie, THE SATANIC VERSES