🚀 go-pugleaf

    Date: Thu, 3 Jun 1999 14:43 EDT
    From: Mike McDonald <mikemac@mikemac.com>


    >From: reti@wilson.ai.mit.edu
    >Date: Thu, 3 Jun 1999 10:58 -0400
    >Subject: Re: Keyboard weirdness. Anyone familiar with this behavior? 
    >To: mikemac@mikemac.com, joswig@lavielle.com
    >
    >    Date: Wed, 2 Jun 1999 18:18 EDT
    >    From: Mike McDonald <mikemac@mikemac.com>
    >
    >
    >    >Date: Wed, 2 Jun 1999 23:47:45 +0200
    >    >To: <reti@wilson.ai.mit.edu>
    >    >From: Rainer Joswig <joswig@lavielle.com>
    >    >Subject: Re: Keyboard weirdness. Anyone familiar with this behavior?
    >
    >    >Sigh!!!! Imagine a MacIvory in a Nubus PowerPC Mac with a
    >    >G3 upgrade card. Better yet a new faster Ivory in a G3 Mac.
    >
    >      Dwelling on the unattainable is only going to depress you. And me!
    >
    >Actually, I've been thinking about doing a MacIvory IV (software only) for
    >the fast PowerBooks.  Would this be something you'd be interested in?  It
    >would probably not have great performance (somewhere between an XL400 and
    >and XL1200, hopefully nearer XL1200 but it will be hard).  The reason is that
    >the 64-bit emulator for the Alpha is already register limited holding more
    >than 32-bit data, so this problem gets much worse on a 32 bit machine.  Also,
    >it will have to do software virtual memory for the 34-bit address space.

      These are just my personal opinions. The firm I work for knows
    nothing about Lisp. (When I told them about CLOS, they were shocked.
    They didn't know lisp even had arrays! I have a LONG task ahead to
    educate these folks. Now, showing them a real lispm environment might
    get their attention.) They also got rid of all of the Macs in the
    company about 18 months ago. 

      Although I'd rather have a x86 version, preferably under Linux, a PB
    version would be interesting. (I understand the difficulties that the
    lack of registers on the x86 gives for performance.) Of course, one of
    the concerns is always cost. Given that there already is MCL for the
    Macs at less than a grand, I'd think Genera priced in the multiple
    thousands range would have very few buyers. (Other than Rainer.) I
    would imagine that if you did a highly tuned emulator, that you'd end
    up charging in the same range as the Alpha version.

      At one time, Symbolics had a more "portable" emulator that was
    written in C. 

It was never finished, hence would be a fair amount of work to get going.
		  
		  I understand the performance wasn't what Symbolics was
    looking for at the time. (Just how bad was it? Say you ran it on a
    400MHz x86, would the performance be in the range of a 3600? 3620?
    XL400? CADR-1?) 
		    
My understanding is that the current emulator was about 10 times faster than
the C emulator, for those instructions actually implemented in the C emulator
(I think just enough to run one of the simple Gabriel benchmarks).  When
added to the slowdowns inherent in running on a 32-bit architecture (more
register pressure for holding > 32-bit quantities, having to do software
virtual memory for the 35 bit address space, etc.), I think this would be
unusably slow.  Of course, that's only a guess.

		    If you could get say 3620 performance out of it
    without much tuning, would a better scheme be to make a variety of
    ports of it available at a smaller (say $500) price? Then, based upon
    the demand for a higher performance version for a particular platform,
    you could then do the fine tuned version and charge correspondingly
    more for it. This approach would have the advantage that you could
    find out where there truely was demand before you invested a lot of
    time and effort in a fine tuned port. It'd also allow people to try
    out Genera without too large of a financial outlay. There's a whole
    generation out there that hasn't even seen a LispM, let alone used one
    enough to know how wonderful the environment is. Somehow Symbolics has
    to find a way to reach them. 

The problem about being available on multiple platforms is not the emulator,
but the life support (written in C and using platform specific features like
packet filters and VM control system calls).  The reason for doing the Mac
is that this life support already exists in nearly usable form for the MacIvory,
so very little work would have to be done on that side.


      Mike McDonald
      mikemac@mikemac.com