Re: Keeping other stuff with addresses

On Wed, 4 Dec 2024 1:43:15 +0000, Keith Thompson wrote:

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

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.

[...]
>
One example of this that I haven't seen mentioned here is used by the C
and C++ compilers for Cray vector machines (I've used the T90 and SV1).
>
These systems had a 64-bit word size, and were heavily optimized
for floating-point operations.  Hardware addresses referred to 64-bit
words.  Compatibility with other systems required support for 8-bit
bytes (CHAR_BIT==8).  This was implemented in generated code by using
the high-order 3 bits of an address as a byte offset.
>
The fact that all byte addressing was implemented in software meant
that, for example, string manipulation was remarkably slow -- but it
worked.

Circa 1983: Lee Higbe (a CRAY compiler writer) told me that the symbol
table lookup process had been completely vectorized and this is why the
CRAY complier and assembler were so fast. Apparently, identifying
symbols and looking them up in the symbol table had been nearly
complete-
ly vectorized.
So, maybe C string functions are slow on word accessed CRAY machines,
But identifying what string of characters is a name and looking it up
in a symbol table CAN be vectorized with the semantics of normal
languages if not with the C intrinsics.

(I'm using the past tense because I don't know whether any of these
systems are still in use.)