brk's zero-fill behavior on VAXen (useful undefined checks)

[Tom Kelly]

In article <363 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
>The CDC Cyber 170 series uses this concept to advantage with most languages;
>since it has 60-bits (a silly number, I agree), it sets all 'bss' storage to
>0600000000000004nnnnn, where nnnnnn is the address of the storage.  Since
>pointers on the Cyber cannot exceed 131071 (0377777), any reference
>to the data as a pointer will fail.  The 06 part is used so that the
>hardware can trap any arithmetic operations on such data as overflow's.

>Ian Donaldson.

This brings back fond memories of working on CDC 6600s (the predecessor
of the Cyber 170 series).  If the word above is executed
as code, it's interpretation is:

		SB0	A0+0	-- has no effect, B0 is hard zero
		PS		-- Program stop

The operating system (at least KRONOS) noticed that the program was
executing a PS and terminated the job with an error message.

I believe that the trap mentioned above only works for floating point,
the bit pattern is a legitimate integer (can't win them all).

The Burroughs B6700 series uses a tagged architecture.  Each memory
word (48 bits) is associated with a 3 bit tag that specifies something
about the associated data (single, double, descriptor, code, ...)

A tag of 6 was reserved for software.  If used as an operand to most
operators, it caused a trap.  A normal store would overwrite a
tag 6, and replace the tag with the correct tag for the
type of data being stored. I worked on a Pascal compiler that
initialized all stack locations with a tag 6.  The compiler would
also put a tag 6 on the word holding the controlled variable in a
for-loop on exit from the loop to enforce the rule that the value
is undefined.  There was some talk of making tag 6 an option for
when memory was initialized by the operating system (normally,
it was set to zero).

I used a similar technique in the Fortran-77 compiler to distinguish
between when an integer variable contained a number and when it contained
a label (set with the ASSIGN statement).  This resulted in a cheap
check that you weren't trying to GOTO an integer value, or do arithmetic
on a label.

Tom Kelly  (416) 922-1937
Human Computing Resources Corp.
{utzoo, ihnp4, decvax}!hcr!hcrvx1!tom