radford@calgary.UUCP (Radford Neal) (03/26/85)
RE: Rob Warnock's extensive analysis of pro's and con's to using the top
eight bits of a 68000 interrupt vector to allow identification of
exception type without 256 interrupt routines.
I have to agree that nowdays 1K of memory for interrupt routine stubs is
not all that much, though it does offend my sense of thrift (perhaps not
a practical sense in this context).
Regarding the use of the top eight bits of addresses for type flags in,
e.g. a Lisp interpreter, which Mr. Warnock still things is a BIG mistake:
I think there's an element of "making of a processor what you want" to all
this. A 68000 can be seen as
1) A machine with 24-bit addresses. You get to use the top 8 bits
of pointers for any old data. (Short-sighted, yes, but sometime
one might have to be.)
2) A machine with 32-bit addresses. You get to address 4 Gigabytes
of memory - great! (At least once you can get a 68020 :-)
3) A machine with 32-bit pointers, the top 8 bits of which
hold information on the type of the object addressed by the
low 24-bits. What an innovation in machine architecture! I
can see the glossies now - "The only processor with hardware
support for object-oriented programming", "Use the languages
of the future on a machine available today", etc. The fact
that it can only handle 16 Megabytes of memory is a minor
limitation not likely to deter anyone wishing to enter the
realm of fifth-generation hardware...
Radford Neal
The University of Calgaryrpw3@redwood.UUCP (Rob Warnock) (03/31/85)
+--------------- | Regarding the use of the top eight bits of addresses for type flags in, | e.g. a Lisp interpreter, which Mr. Warnock still thinks is a BIG mistake: +--------------- I'll give it one more volley, then quit, o.k.? I do love a good debate, but one can lecture about "purity" just so long before it becomes boring, eh? ;-} The "mistake" I'm talking about is not the use of the high bits per se, but the unrestricted proliferation of dependence on that choice of implementation outside of the "type mechanism", so that it later becomes impossible to de-commit that PARTICULAR implementation should a different one be desired later (such as *hardware* that supports cell types), or should the bits be needed for some other use (such as expanding memory). Just as I had no problem with the use of the high bits in the interrupt vector case -- IF that use is encapsulated in the interrupt system -- I have no fundamental objection to their use for typing, PROVIDED that only one (small) "type module" knows of that use. (Note: A "module" may comprise macros, so there is not necessarily a performance penalty -- see Parnas's papers on modularity.) However, my concern is that "in the real world" -- i.e., programming as it is most commonly practiced -- it is VERY difficult to maintain such clean modularization in the face of various organizational pressures (documented by others at length elsewhere), and that use of details of the implementation will filter into places that will cause problems later. Therefore we should use as "clean" and "safe" designs as possible. Of course there are real constraints of performance, economics, and even (*gasp*) delivery time. But even in the face of these, we should maintain our vigilance against what Dijkstra calls "complexity generators". +--------------- | ...A 68000 can be seen as | 1) A machine with 24-bit addresses. You get to use the top 8 bits | of pointers for any old data... | 2) A machine with 32-bit addresses. You get to address 4 Gigabytes | of memory - great! (At least once you can get a 68020 :-) +--------------- Or a 68012 (available in quantity now?). +--------------- | 3) A machine with 32-bit pointers, the top 8 bits of which | hold information on the type of the object addressed by the | low 24-bits. What an innovation in machine architecture! | Radford Neal | The University of Calgary +--------------- Yes, each of those views has its uses, and each has its problems. Tanstaafl. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404