Re: in defense of C

["lawrence.g.mayka" <att!cbnewsc!lgm@bloom-beacon.mit.edu>]

In article <1942@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
> >One of the most important quality measures of a Common Lisp
> >compiler is the level of safety it supports without an undue
> >sacrifice in execution speed.  The better CL implementations score
> >quite highly on this scale, especially on newer processor
> >architectures such as SPARC.  For example, the better compilers
> >indeed ensure that CAR and CDR are only applied to lists, without
> >a loss of execution speed and even though a CL implementation must
> >permit one to apply CAR and CDR to the symbol NIL.
>
>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?  If so, I would
>expect that safety to remain even if I set saftey=0, but that doesn't
>seem to be what happens.  Moreover, how many of the SPARC compilers
>can do this?  I suspect it's only one or two of them.

You may be right.  The particular compilation "trick" I've seen
relies on the processor hardware to trap a fullword-size reference
to a machine address not aligned on a fullword boundary.  But if,
as I think is true, the 68020 silently satisfies unaligned pointer
references, this particular technique will indeed be ineffective
on that architecture.

All the more reason to upgrade to a RISC-based computer...


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.