marick@m.cs.uiuc.edu (08/09/90)
Lisp objects are typed at runtime. This is usually implemented by using tag bits in the pointers to those objects. Objects small enough to fit in a word have tag bits that say, "I'm not a pointer; I'm a short integer" or whatever. In Lucid's Common Lisp, they used the two low-order bits as the tag. On a machine that simply ignored the low-order bits on dereferencing, they could avoid masking those bits off. I don't know whether they did so. Another advantage of this scheme is that the tag bits for short-integers are 0. No masking is needed before addition, and overflows can be detected by hardware. You do have to remember to shift integers before output. The Gould Powernode machines had 32 bit words, 24 bit addresses. The top 8 bits were ignored. In our Lisp, we put the tag bits there. Again, there was no need to mask before dereferences. The tag bits for positive short ints were 0x0 and for negative short ints were 0xff, so machine addition could be used without masking. However, you had to check for overflow into the tag bits. (Note: I didn't work for Lucid. As I recall, I learned this with their debugger. I think the trick has been floating around for a while.) Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick
richard@aiai.ed.ac.uk (Richard Tobin) (08/14/90)
In article <3300155@m.cs.uiuc.edu> marick@m.cs.uiuc.edu writes: >In Lucid's Common Lisp, they used the two low-order bits as the tag. >On a machine that simply ignored the low-order bits on dereferencing, >they could avoid masking those bits off. I don't know whether they >did so. It's possible to make use of the fact that most machines *don't* ignore the low-order bits to get "free" type checking. Suppose you make the tag for cons cells 3, and address them something like this: move -3(r1), r0 This will cause a trap if the tag is not 3. Whether the type check is really free depends on whether you would have been able to use a faster addressing mode if you didn't want the check. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
peterson@primerd.prime.com (08/15/90)
/* Written 10:45 am Aug 12, 1990 by pinocchio.encore@encore.UUCP in primerd:comp.arch */ /* ---------- "Re: Is handling off-alignment impor" ---------- */ From article <488@array.UUCP>, by colin@array.UUCP (Colin Plumb): >>>mash@mips.COM (John Mashey) writes: >>>> Can anyone give some live examples where software takes advantage of the >>>> mode where the CPU just zeroes the low-order bits and conitnues... > >>jkenton@pinocchio.encore.com (Jeff Kenton) writes: >>> The only case I've seen is a low level, PROM based, debugger on the 88k >>> which runs in this mode. > > In article <467@hitachi.uucp> jon@hitachi.UUCP (Jon Ryshpan) writes: >> I can't imagine a *worse* place to turn off a trap detecting possible >> errors than in a debugger. > > I think we can assume that it restores the state while running the debugged > code; it just turns off the trap for internal use. I don't think detecting > errors in the PROM monitor does you much good, anyway, so why worry? :-} Unfortunately, it doesn't. As I said in my (partially quoted) posting, I'm not convinced that the small saving in debugger code is worth the loss of general error checking it costs you. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com --- always at (617) 894-4508 --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* End of text from primerd:comp.arch */
hascall@cs.iastate.edu (John Hascall) (08/15/90)
In article <3300155@m.cs.uiuc.edu> marick@m.cs.uiuc.edu writes: }The Gould Powernode machines had 32 bit words, 24 bit addresses. The }top 8 bits were ignored. In our Lisp, we put the tag bits there. }Again, there was no need to mask before dereferences. The tag bits... As someone who went through a conversion from MVS to MVS/XA I find this perfectly horrible.
msf@rotary.Central.Sun.COM (Mike Fischbein) (08/16/90)
In article <2458@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: >In article <3300155@m.cs.uiuc.edu> marick@m.cs.uiuc.edu writes: > >}The Gould Powernode machines had 32 bit words, 24 bit addresses. The >}top 8 bits were ignored. In our Lisp, we put the tag bits there. >}Again, there was no need to mask before dereferences. The tag bits... > > As someone who went through a conversion from MVS to MVS/XA I find >this perfectly horrible. You don't need to wait; the Gould NP line had a lot of compatability with the Powernodes; but they did use all 32 bits of address. Has anyone mentioned GNU Emacs using high order address bits yet? mike -- Michael Fischbein, Technical Consultant, Sun Professional Services Sun Albany, NY 518-783-9613 sunbow!msf or mfischbein@east.sun.com These are my opinions and not necessarily those of any other person or organization. Save the skeet!
marick@m.cs.uiuc.edu (08/16/90)
>> As someone who went through a conversion from MVS to MVS/XA I find >>this perfectly horrible. > > You don't need to wait; the Gould NP line had a lot of compatability > with the Powernodes; but they did use all 32 bits of address. One of the easier parts of porting Powernode lisp to the NP was dealing with the fact that tag bits were now valid address bits. We knew how we'd do it well in advance. Taking advantage of architectural quirks isn't automatically evil. You just have to weigh the costs against the benefits. Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick
davec@nucleus.amd.com (Dave Christie) (08/17/90)
In article <3300161@m.cs.uiuc.edu> marick@m.cs.uiuc.edu writes: > >>[in some other article someone understandably writes:] >>> As someone who went through a conversion from MVS to MVS/XA I find >>>this perfectly horrible. > >One of the easier parts of porting Powernode lisp to the NP was >dealing with the fact that tag bits were now valid address bits. We >knew how we'd do it well in advance. > >Taking advantage of architectural quirks isn't automatically evil. >You just have to weigh the costs against the benefits. Unless you know what the architects might come up with in the future in the way of architectural extensions, you can't know all the possible costs. -------------------- Dave Christie My opinions only.
jbuck@galileo.berkeley.edu (Joe Buck) (08/18/90)
In article <1990Aug17.155925.1588@mozart.amd.com>, davec@nucleus.amd.com (Dave Christie) writes: > In article <3300161@m.cs.uiuc.edu> marick@m.cs.uiuc.edu writes: > >Taking advantage of architectural quirks isn't automatically evil. > >You just have to weigh the costs against the benefits. > Unless you know what the architects might come up with in the future > in the way of architectural extensions, you can't know all the possible > costs. If your software design makes use of information hiding, then all code that depends on the architectural feature will be localized to a very small portion of code, so converting to a new architecture will be easy. If you don't use this kind of discipline, yes, porting your software to a new architecture, or even the next generation of the same architecture, will be extremely difficult, because cruft that depends, say, on the meanings of particular bits will appear all over the place. Yet another reason I'm growing to like C++ more and more... -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
aglew@lasso.crhc.uiuc.edu (Andy Glew) (08/18/90)
Hi Dave! Hi Brian! Mind if I jump in? >>Taking advantage of architectural quirks isn't automatically evil. >>You just have to weigh the costs against the benefits. > >Unless you know what the architects might come up with in the future >in the way of architectural extensions, you can't know all the possible >costs. Within a company, "architects" should have long range plans for the direction of the architecture, and should be able to give software developers for that architecture an idea of what the costs will be. Of course, the plans will change, sometimes breaking previously stated cost goals (but hopefully not breaking previously stated compatibility rules). If you haven't got a rough idea of where you are headed in 5 years' time (I'd like to say 10 years' time, but most US companies don't think that far ahead (except maybe IBM)) you aren't architecting, you're implementing. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
marick@m.cs.uiuc.edu (08/22/90)
> I assume the architectural quirks that Brian was referring to are the > grey areas in any architectural definition covered by such phrases as What I meant is simple. Tying software architecture to a support architecture is always a matter of evaluating risks and benefits. There is no difference in kind between the decisions to depend on POSIX, on SunOS, on the 68K, or on a particular architectural feature of the Gould PN machines. Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick