Xref: utzoo comp.lang.lisp:2887 comp.lang.scheme:1147 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: in defense of C Message-ID: <1990Mar8.115308.6180@hellgate.utah.edu> Date: 8 Mar 90 18:53:08 GMT References: <1903@skye.ed.ac.uk> <14112@cbnewsc.ATT.COM> <1942@skye.ed.ac.uk> <542@fsu.scri.fsu.edu> Organization: University of Utah CS Dept Lines: 31 In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: >In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: >> You say this as if it were typical of better compilers on machines >> other than SPARCs, such as, maybe, 68020s. Can they really have safe >> CARs and CDRs, without loss of speed, on a 68020? > >I don't know about the internals of any LISP system other than the ones I >have written. In the one I am now writing for the 680x0, one can have >safe CARs and CDRs without loss of speed. One has to test to see if it is >(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for >(1) a valid list, or (2) anything else. In my system, that's testing a >single bit. In case 1, do the job. In case 2, return NIL. > That's the loss of speed that Jeff is talking about. If you assume that the argument to CAR or CDR is a cons cell or NIL and you have a low-tags type scheme, then those operations are 1 instruction long on a 680x0 (or even less: a base-displacement addressing mode). The NIL case can be handled with a bit of symbol table trickery. A "safe" C{A,D}R that checks its argument is going to be slower. >Eric Pepke INTERNET: pepke@gw.scri.fsu.edu >Supercomputer Computations Research Institute MFENET: pepke@fsu >Florida State University SPAN: scri::pepke >Tallahassee, FL 32306-4052 BITNET: pepke@fsu > Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters