[net.micro.amiga] Use of high-order byte of addresses in 680x0 software

gnu@l5.uucp (John Gilmore) (12/03/85)

This issue came up in January in net.micro.mac; now that we have a
new crop of people writing for a new crop of machines, let me reiterate
what Dale Luck (of Amiga), Rob Warnock (ex of Fortune, now independent),
and I (ex of Sun, now independent) have been saying:

"Don't use the top byte of a 32-bit address as anything but a piece of
the address.  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 24-bit addressing is not part of the
instruction set (it was defined as 32 from the start).  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 machine with a data cache that doesn't deal well with
aliasing, it could also cause incorrect results.  (Data caches are
often used to get maximum speed out of e.g. 20MHz 68020s)."

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

The CSA/Amiga board is a great example:
> >Well, the 68020 puts out all 32 bits.  But does the system use them?  If
> >it doesn't, then it should be ok to play games with these bits.
> CSA's amiga/68020 board has 256k of memory. It was configured to be
> at 7f000000-7f03ffff. This caused a hickup in one of our libraries since
> it was internally using some of the 8msb as some flags. That got changed
> REAL FAST.  We advise all those that wish to write software that is
> hoped to run on compatible but more powerful products to assume that all
> pointers are 32 bits.

Sun-3's check to make sure you aren't using any of those bits, so that
when larger models come along (currently 256MB address space, but there
are four whole unused bits up there!) any software that now runs won't
break.  Happily, few folks writing Sun-2 software had screwed this up,
so much of it runs on Sun-3's without trouble.

radford@calgary.UUCP (Radford Neal) (12/06/85)

> This issue came up in January in net.micro.mac; now that we have a
> new crop of people writing for a new crop of machines, let me reiterate
> what Dale Luck (of Amiga), Rob Warnock (ex of Fortune, now independent),
> and I (ex of Sun, now independent) have been saying:
> 
> "Don't use the top byte of a 32-bit address as anything but a piece of
> the address..."

I don't want to rekindle the whole discussion, but I thought I'd put in
the other side of the argument, at least as it existed in net.arch:

  "Use the top byte of a 68000 address for something else (like the type of
  the object pointed to) if this is sufficiently important to your application
  that it's worth sacrificing expandability of memory past 16MB. Don't
  be surprised if this isn't very portable to other 68000 systems."

I don't advocate this usage just to save 10% on data space for your 
program. It's more for something like a Lisp interpreter where tag bits
can greatly enhance performance and implementation simplicity. You ought
to be prepared to think of the processor, not as a 68000, but as some
new micro with a 16MB address space and nifty typed pointers.

     Radford Neal