Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

scott@slp53.sl.home (Scott Lurndal) writes:

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

John Levine <johnl@taugh.com> writes:

S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
the high 8 bits of the register were ignored. That turned out to be a really bad
decision since a few instructions and a lot of programming conventions stored
other stuff in that high byte, causing severe pain a few years later when
memories got bigger than 16 meg.

>
The technique of putting stuff in unused bits of an address has its
drawbacks, but it also has benefits, in particular type information is
often stored there (even on architectures that do not ignore any
bits).  Of course AMD and Intel have the bad examples of S/360 and
68000 in mind, and did not want to have anything to do with that
during the first two decades of AMD64.
>
The designers of ARM A64 could think beyond that and designed in the
top-byte-ignore feature.  Apparently this made AMD and Intel see the
light:
>
AMD added the upper-address ignore feature, which, when enabled,

>
Architecturally known as Top Byte Ignore (TBI).  It can be
independently enabled for each half of the virtual address space
(based on the value of VA<55>).
>
>

ignores the top 7 bits.

AMD calls it the upper-address ignore feature, and it does not ignore
the top byte.  As mentioned above ARM has the top-byte-ignore
feauture, which ignores the top byte.

Making a difference between kernel and user space is interesting.  The
kernel is usually not implemented in a programming language with
dynamic typing, so it does not need TBI for that reason; it may want
it for the other uses: pointer authentication and maybe memory
tagging.  At the kernel level pointer authentication sounds useful for
finding cases where addresses coming from user space are used without
first being checked (and converted to authenticated pointers).

The other direction is to have TBI for user space (for a process
running a Lisp program or somesuch), but not for the kernel space.
For the kernel this would allow techniques such as mapping physical
RAM into the kernel space even for RAM sizes up to 2^62 bytes ("only"
2^54 bytes, i.e., 16 Petabytes with the kernel in TBI mode).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>