Path: utzoo!attcan!uunet!husc6!yale!lisper-bjorn
From: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper)
Newsgroups: comp.arch
Subject: Re: negative addresses (really unsi
Message-ID: <29409@yale-celray.yale.UUCP>
Date: 17 May 88 04:21:56 GMT
References: <11571@ut-sally.UUCP> <28200145@urbsdc> <11618@ut-sally.UUCP> <493@cmx.npac.syr.edu>
Sender: root@yale.UUCP
Reply-To: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 39

In article <493@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O'Farrell)
writes:
(Ed Nather writes about the problems with counting photons from stars)
>>Unfortunatly I have found no simple way to get the star to cooperate with
>>respect to counting rates.  Sometimes 16 bits are enough, sometimes 32
>>aren't, depending on the the star's brightness and the rapidity with which
>>it varies.
>
>This is a perfect example of why we need higher-level languages
>like lisp.  In lisp, you don't need to know the ranges of 
>integers ahead of time. If your calculations overflow the
>hardware representation of an interger, lisp just converts
>the representation to Bignum, and works with it instead --
>you may never even be aware that the conversion has occurred.

A lisp implementation has other problems. Counting photons is a real-time
application and lisp is not very well equipped to deal with this. What if
the lisp interpreter decides to do a garbage collection just when a bunch of
photons are coming? Hiding representations is a nice idea but this is a
particular application where one must have close control of the
representation because of the real-time constraints.

>Yes, we need languages that are close to hardware (I don't think I'd
>be able to write an operating system for, say, an IBM 370, in lisp.)
>But much of programming could be made easier if we used (and designed)
>languages more suited to the framing of algorithms rather than to the
>writing of programs which run fast on particular pieces of hardware.
>
>In fact, using such languages has the beneficial effect of encouraging
>the design of hardware better suited to higher-level language
>implementation -- example: lisp machines.

When we are at the subject, has anyone heard anything lately about the
Japanese fifth-generation computer project related ideas to have extensive
hardware support for prolog and use it as a machine language? There was a
lot of talk about this back in -83 but since then I haven't heard too much.
This is another idea I've never believed in.

Bjorn Lisper