[gclist] Memory cheats and VM (was Counting on one thumb)

[John Carter]

On Fri, 17 Jan 1997, Richard A. O'Keefe wrote:

>  _I_ find it hard to believe that brute force copying would usually
> be cheaper than 2 instructions.
Ok, maybe you have convinced me. Actually 3 instructions, you forgot
to inc the refcount.

> 	Or is this a relict (sic) of memory short days like ye olde
> 	Vax BLISS?
> I have used BLISS-10 on a DEC-10, and I've seen BLISS-32.
> They were even lower level than C.  You can use BLISS-32 on a VAX
> with hundreds of megabytes of memory.  I don't see any connection here.

As I remember it from one the Dec marketing brochures Bliss was
designed to be highly memory efficient. VMS showed scars of this. Most
SYS$ calls had horrible parameters that required very tedious, (in C),
packing of structs and bit strings. I remember the feeling of woe
coming over me every time I needed to call a SYS$ library routine,
because the damn things were clearly designed to be called from BLISS
for the SYS$'s and from Fortran for the LIB$ calls. From C you had to
guess or scratch in the Fortran manual to work out how to create the
right structs and passing mechanisms.

> Come off it!
> There is *never* any need to copy *immutable* 'objects' of any kind.
> Integers and floating point numbers are intrinsically immutable.
> Copying (and copy optimisation) only apply to *mutable* objects,
> where there is some operation that can change some *part* of an object.
Huh? I'm confuzzled. Speaking C++ because it so easy to illustrate
messes in...

	int i, j, * ip, & k = j;
	j = 3;
	ip = &j; // j is aliased.
	i = j; // j is copied.
	*ip &= 1; j is mutated.
	k &= 2; // j is zero.

This is semantically or practically no different from
	char c[ 100], j[]="I agree.", * cp;
	cp = j; // Alias
	strcpy( c, j); // copy
	strcpy( cp + 2, "refute you."); //mutate

Or not so easy to spot...
	fun( int i, int& k)
	{
	  i &= 1; // Copy of j mutated.
	  k &= 1; // j mutated.
	}

	int j = 3;

	fun( j, j);

Or what happens here...
	zero( int& i, int& j)
	{
	  i &= 1;
	  j &= 2;
	  return i | j;
	}
	int j = whatever;
	cout << zero(j, j) << '\n';


In the Actor language I would agree with you. Partially. To facilitate
GC they made all variables hold an object pointer that pointed to an
entry in the object table. The object table held the object type, some
flags and a pointer to where the item actually was. Thus GC could
fiddle the pointers in the object table without munching the users
program. As an optimization trick they used bit 15 of the object
pointer as a flag to indicate that the Object Pointer was actually a
15 bit short integer not an object pointer. You could think of this as
having 32k spaces of the Object Table as reserved (virtually speaking)
for the short ints. Thus saying "i := i bitand 1" resulted in i
pointing to a different (virtual) object. Reals and LongInts required
an object pointer, but I dare say they may have stored the value in
the object table rather than a pointer.

> The trouble is that an 80*86 hasn't got very _many_ segments.
> Even on the high end machines, segment registers are 16 bits,
> and typically user software can use half of the segment numbers.
> Since you'll probably need a code, stack, and data segment to get off
> the ground, and it's handy to have a spare, this means programming
> with a limit of 32764 objects.  That seems rather small.
Damn. I've just checked. You right. You worse than right. Because you
have to divide that by 8 for this that and the other. Oh well,
that one is down the tubes.

> Just think about being stuck on one machine, not being able to use an
> Alpha or a PowerPC or an R10000 or ...

Just think of being stuck for all time to doing only what you could do
in MS-DOS on a 8086. Its time to move on beyond the Lowest Common
Denominator.


John Carter                    EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338

Founder of the Council for Unnatural Scientists.