🚀 go-pugleaf

+---------------
| I've been playing around with sumacc C programming and had to do a little
| programming in assembly language to handle some special cases.  I've
| noticed that the high byte of an address (the 68000 only uses the bottom
| 24 bits) is used alot in the Mac for special purposes.  However, even when
| I do a Load Effective Address (lea) command, the high byte is sometimes
| non-zero and I have to clear it out.  Does anyone know if the hardware in
| the Mac uses that high byte for something?
| Edward Moy | edmoy@ucbopal | ucbvax!ucbopal!edmoy
+---------------

<Anguished Flame>
NO, NO! SAY IT ISN'T SO! If they have done this, it's going to be a major
disaster when they go to a 68020, where those bits are significant. Don't
we learn ANYTHING from our mistakes in this industry? Wasn't it enough that
all those 360 programs had to be re-written for 370s???????? I don't expect
the front line troops to remember (they're too young in many cases), but
doesn't Management ever come to design reviews? Using "spare" bits for
cutesy tags is simply too dangerous to consider (unless the usage is tightly
confined to a few SMALL modules you plan on replacing in the next generation).

((...and even then, clever users will discover them, use them, and be greatly
upset when you take them away...))


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404

> I've noticed that the high byte of an address (the 68000 only uses the bottom
> 24 bits) is used alot in the Mac for special purposes.

Well, let's hope that no future Mac software ever desires >16MB of address
space (which will probably be true for quite a while) - a certain big blue
computer company started doing this ~20 years ago on a certain line of their
computers; now that they're running out of address space, they had to
introduce a mode bit into their machines, and a whole new version of the
OS to handle it, and the trade tabloids are *still* talking about the
hassles of converting to MVS/XA.

The 68012 and 68020 don't have mode bits, although if the upper 8 bits don't do
anything other than leave the chip on appropriate pins, this can be handled
in off-chip logic (i.e., run those lines to /dev/null).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

The reason the high byte gets trashed in SumacC code has nothing to do
with the Mac hardware, but instead is a side-effect of the Sumacc
relocation scheme.  Unlike the Lisa/Workshop Pascal compiler, Sumacc
does not generate position independant code.  Since C compiler and
loader have no way of knowing where the code will be loaded (this is
decided dynamicly by the Mac memory manager), addresses are resolved
every time a Sumacc program starts up.  

To resolve addresses at startup time, Sumacc uses a "clever" scheme of
run-length encoding relocation info into the high order byte of addresses
that need relocating.  The gory details of how this works can be found
by looking in crtmac.s in the Sumacc lib/ subdirectory.
 

I'm in total agreement with Rob Warnock on the use of upper bytes of
32-bit addresses.  I saw the IBM 360 folks get burned by it and don't
intend to let any enterprise I'm associated with do it again.  This
kind of usage does NOT automatically break when you install a 68020
(the way it did in the IBM systems), since it's not part of the
instruction set.  Instead, it breaks if you ever hook up more than 24
address wires to any 68000 family member (eg 68012, 68020) that brings
these bits out to pins.  It DOES decrease cache performance in the
68020, since the same piece of code can be accessed at addresses which
the cache thinks are different.  In a data-cache based machine that
doesn't deal well with aliasing, it could also cause incorrect
results.

This whole topic has previously been discussed in net.micro.68k.

A few comments on the SummacC relocation stuff (without knowing it
personally):
	1.  It was probably expedient and it certainly worked.
	2.  It was easier than changing the C compiler.
	3.  It is not portable to larger machines.
	4.  There will be Mac-class machines with >16MB within 5 years.
	5.  There's nothing as permanent as a temporary kludge.
	6.  At least they could have cleared the high bytes after doing
	    the relocation, so the running program would not know the
	    difference.

A side comment, the 'LEA' instruction, like all address arithmetic in the
68000 family, operates on a full 32 bits.  In the 360, the equivalent "LA"
instruction cleared the high byte; this was a major problem ten years
later.

In article <130@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes:
>+---------------
>| programming in assembly language to handle some special cases.  I've
>| noticed that the high byte of an address (the 68000 only uses the bottom
>| 24 bits) is used alot in the Mac for special purposes.  However, even when
>+---------------
>NO, NO! SAY IT ISN'T SO! If they have done this, it's going to be a major
>disaster when they go to a 68020, where those bits are significant. Don't

They could always just leave the upper eight address lines unhooked
on the 68020, thereby staying compatible! :-)
-- 
Duty Now for the Future
					Tim Smith
			ihnp4!wlbr!callan!tim or ihnp4!cithep!tim