mm3d+@andrew.cmu.edu (Matt McNally) (12/02/89)
I'm not sure it really matters, but here goes...
After looking at the MPW 3.0 default make files generated
with the 'Create Build Commands...' option I noticed that
the *new* default is to link with the '-ad 4' option.
Now I *think* I understand what the option does, as describe
in the MPW manuals but I have no idea WHY I would want to align
data to 4 byte (2 word) boundaries as opposed to single word
(2 byte) boundaries.
Can anyone clarify this for me? Should I re-link my older
programs using this option? Does it have something to do
with different addressing modes across the 680x0 processors ?
What affects will using it (and its sister option '-ac n') have
on a application?
Bewildered,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Matt M. McNally - 'Macintosh II Initiative' Research Programmer/Dugan
Carnegie Mellon, H&SS Dean's Office, Pittsburgh 15213
mm3d@andrew.cmu.edu | Baker Hall 369B, (412) 268-6990
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
tim@hoptoad.uucp (Tim Maroney) (12/02/89)
In article <oZReQbO00UhWQ1WF02@andrew.cmu.edu> mm3d+@andrew.cmu.edu (Matt McNally) writes: >After looking at the MPW 3.0 default make files generated >with the 'Create Build Commands...' option I noticed that >the *new* default is to link with the '-ad 4' option. > >Now I *think* I understand what the option does, as describe >in the MPW manuals but I have no idea WHY I would want to align >data to 4 byte (2 word) boundaries as opposed to single word >(2 byte) boundaries. John Gilmore (the system administrator and owner of hoptoad) just explained this to me the other day, in response to my slightly flawed message on alignment errors in 680x0 processors. The 32-bit data bus processors (68020, 68030) can cope with data on any alignment, but it will take an extra bus cycle to cope with unaligned data, because the processor has to do two fetches. So there's some performance gain on true 32-bit processors if all data is aligned at a four-byte boundary. (Actually, I think this only applies to longwords; John? I don't see how there would be any gain for one-byte or two-byte data, as long as the two-byte data is aligned at a two-byte boundary. I gotta get me a 68030 manual one of these days; this old 68K one I've been using for years is not real helpful on this kind of question.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "He goes on about the wailing and gnashing of teeth. It comes in one verse after another, and it is quite manifest to the reader that there is a certain pleasure in contemplating the wailing and gnashing of teeth, or else it would not occur so often." -- Bertrand Russell, "Why I Am Not a Christian"
ari@eleazar.dartmouth.edu (Ari Halberstadt) (12/04/89)
Here's a question for you folks out on NetLand. I'm trying
to figure out, with a reasonable degree of success, if the refCon
field of a window contains a valid handle. This must be determined
by a driver, which is separate from the the program which actually
created the window. The tests currently performed are:
Boolean ValidHandle(Handle hndl)
{
hndl = (Handle) GetWRefCon(window); /* copied here for brevity */
if (! hndl)
return(false);
if ((long) hndl & 1L) /* check for odd address */
return(false);
if (GetHandleSize(hndl) != expected_size)
return(false);
}
Actually, I've got three questions.
1. Is it ok to check for odd adresses on a 680x0? I assume Apple
wouldn't write NewHandle to create something on an odd adress, since
access times are slower.
2. I would like to check that the handle is within a reasonable area
of memory, i.e., within the application heap. However, since the
application may have several heap zones, what is the correct way to
check this? Is it sufficient to use ApplicZone and GetApplLimit?
3. Any more ideas for useful checks? I've already got a special
long int stuck at the head of the place where the correct handle
would point to, and I've thought of making sure the handle is
below RomBase.
--
Ari Halberstadt '91, "Long live succinct signatures"
ari@eleazar.dartmouth.edu Disclaimer: "Live Free or Die"