Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!tmb
From: tmb@talcott.UUCP (Thomas M. Breuel)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: Re: 24 bit vs. 32 bit address space
Message-ID: <342@talcott.UUCP>
Date: Sat, 9-Mar-85 00:52:37 EST
Article-I.D.: talcott.342
Posted: Sat Mar  9 00:52:37 1985
Date-Received: Mon, 11-Mar-85 05:38:12 EST
References: <983@watdcsu.UUCP>
Organization: Harvard University
Lines: 43
Xref: watmath net.arch:950 net.micro.16k:271 net.micro.68k:652

> >       2) Using the top bits for type information can be VERY attractive
> >          in a Lisp implementation. On machines without unused address
> >          bits, this is often simulated by allocating all objects of one
> >          type from one pool of memory (or various variations on this). 
> >          The simulation isn't as good as really having unused address
> >          bits however...
>  
> NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO !!!!!!!!!!!
> 
> [...]
>
> Soooooooo.  If a block of 32 bits is DEFINED as the size of the address
> field for an instruction, regardless of how many are actually USED, 
> keep your @*$$#@ fingers off of the unused bits.  As certainly as the
> daily sunrise, someone will have to port that code to a version of the
> machine in which those bits ARE used.  If you have been clever and were
> seduced by the attraction of using those bits to spiffy up your
> implementation, you can be certain that those who follow you will
> loudly express unkind opinions about your ancestry.

If I can increase memory utilisation in a symbolic language by 30% 
without work and without making it slower, then by all means I do it,
regardless of whether it involves putting tags into pointers. In
particular I do it when the program is supposed to run on a micro
with maybe 1/2M real memory.

The other approach to implementing tagged pointers, namely a spaced
heap, is equally unportable. If you try to port something like
'CProlog' or 'Franz' to anything without virtual memory (e.g. a
PDP-11) you run into a lot of trouble as well.  With just 64k of
address space, allocating megabytes for different heaps in 'virtual
memory' just doesn't work.

Storage allocators will always be system dependent if they are to be
efficient. And in a programming language like LISP, the storage
allocator better be efficient.

The only approach to writing portable software is to follow the rules
of data abstraction, information hiding, and modularisation strictly,
not to make your programs so inefficient that nobody cares to port
them.

						Thomas.