Kaelin Colclasure <······@everest.com> writes:
> Just an idle curiosity -- but did Lisp machines provide garbage
> collection at the level of kernel modules and device drivers?
Not that I've ever used a Lisp machine, but from what I've read, it
seems like there is no kernel/user distinction on a Lisp machine -
everything is just Lisp, but at a graduated degree of abstraction.
So I would think that even objects allocated at a "low" level could be
collected by the GC.
Colin Walters <·········@cis.ohio-state.edu> writes:
> Kaelin Colclasure <······@everest.com> writes:
>
> > Just an idle curiosity -- but did Lisp machines provide garbage
> > collection at the level of kernel modules and device drivers?
>
> Not that I've ever used a Lisp machine, but from what I've read, it
> seems like there is no kernel/user distinction on a Lisp machine -
> everything is just Lisp, but at a graduated degree of abstraction.
On most of the Lisp machines there was a microcode layer that was
definitely not Lisp.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Barry Margolin
Subject: Re: Did Lisp machines provide GC for kernel-level code?
Date:
Message-ID: <FcI76.60$IL1.373@burlma1-snr2>
In article <············@content-integrity.com>,
Joe Marshall <···@content-integrity.com> wrote:
>Colin Walters <·········@cis.ohio-state.edu> writes:
>
>> Kaelin Colclasure <······@everest.com> writes:
>>
>> > Just an idle curiosity -- but did Lisp machines provide garbage
>> > collection at the level of kernel modules and device drivers?
>>
>> Not that I've ever used a Lisp machine, but from what I've read, it
>> seems like there is no kernel/user distinction on a Lisp machine -
>> everything is just Lisp, but at a graduated degree of abstraction.
>
>On most of the Lisp machines there was a microcode layer that was
>definitely not Lisp.
True, but as far as OS developers were concerned, that layer could usually
be considered part of the hardware.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <··············@soyuz.arslogica.com>, Kaelin Colclasure
<······@everest.com> wrote:
> Just an idle curiosity -- but did Lisp machines provide garbage
> collection at the level of kernel modules and device drivers?
>
> -- Kaelin
Can't speak for Lispms in general (TI, Xerox, LMI, ...).
The Symbolics Lisp Machines have a multitude of memory management
techniques. Three GC systems (full, dynamic, ephemeral),
GC modes (incremental, immediate), generational, copying,
mark&sweep, In-Place, by-area, ... Plus "manual" memory management.
Memory is organized in areas (improving locality) - where
each area can have different memory management and
paging strategies. One can say at object creation which area to use
for allocation. Areas are devided into "Regions".
Some areas might not be GCed at all (static).
Manual management also uses "resources".
If it is written in Lisp (almost everything is), it will
have to use one or more of the memory management strategies.
Networking code uses for example "wired" packets. The
system makes extensive use of manual memory management.
Also remember that there is not really much of "kernel
modules" and "device drivers" - most stuff is just
a type (foreground, background, deadline)
of Lisp thread (even the mouse has it's own thread)
with a certain priority. All is running
in one big multi-threaded Lisp image.
During a full GC this system might not respond to
anything from the keyboard, network, etc. Dynamic and
Ephemeral GCs can (and usually are) run in parallel
to other processes. The ephemeral GC is very effective
and nearly unnoticable. The dynamic GC is not so
nice (and runs for several hours on my home system - GCing
several hundred MBs of virtual memory).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
[...]
> If it is written in Lisp (almost everything is), it will
> have to use one or more of the memory management strategies.
> Networking code uses for example "wired" packets. The
> system makes extensive use of manual memory management.
Are you referring here to "resources-style" manual memory management,
or explicit deallocation? It would be interesting to see just how
much of the low-level code was deemed to need manual memory management.
> Also remember that there is not really much of "kernel
> modules" and "device drivers" - most stuff is just
> a type (foreground, background, deadline)
> of Lisp thread (even the mouse has it's own thread)
> with a certain priority. All is running
> in one big multi-threaded Lisp image.
Hmmm, are there no privilege rings? I suppose at the time this might
have been deemed unnecessary for what was primarily a single-user
system?
> During a full GC this system might not respond to
> anything from the keyboard, network, etc. Dynamic and
> Ephemeral GCs can (and usually are) run in parallel
> to other processes. The ephemeral GC is very effective
> and nearly unnoticable. The dynamic GC is not so
> nice (and runs for several hours on my home system - GCing
> several hundred MBs of virtual memory).
Ouch! :-)
-- Kaelin
Kaelin Colclasure <······@everest.com> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> [...]
> > If it is written in Lisp (almost everything is), it will
> > have to use one or more of the memory management strategies.
> > Networking code uses for example "wired" packets. The
> > system makes extensive use of manual memory management.
>
> Are you referring here to "resources-style" manual memory management,
> or explicit deallocation? It would be interesting to see just how
> much of the low-level code was deemed to need manual memory management.
For the networking code, you don't want the GC to move you packets
around while you are trying to get the ethernet card to dma them out
to the wire. In these cases, you would use explicit allocationd and
deallocation.
> > Also remember that there is not really much of "kernel
> > modules" and "device drivers" - most stuff is just
> > a type (foreground, background, deadline)
> > of Lisp thread (even the mouse has it's own thread)
> > with a certain priority. All is running
> > in one big multi-threaded Lisp image.
>
> Hmmm, are there no privilege rings?
No.
> I suppose at the time this might have been deemed unnecessary for
> what was primarily a single-user system?
It wasn't so much that as the fact that erroneous lisp code can't
destroy data structures the same way as, for example, erroneous C
code. The integrity of the heap was protected by the microcode, and
the type checking hardware would quickly raise an error when bad data
were passed to primitives.
It was *possible* to write malicious code that would do some
entertaining things (a story for another time), but it wasn't often
that a lisp process would bring down the entire machine when it caused
an error.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
>>>>> "Joe" == Joe Marshall <···@content-integrity.com> writes:
Joe> It was *possible* to write malicious code that would do some
Joe> entertaining things (a story for another time), but it wasn't
Joe> often that a lisp process would bring down the entire machine
Joe> when it caused an error.
I'd love to hear about this. Actually, anything you have to say about
the security model of the LispM would be interesting. I'm sure others
here feel the same way. Tell us a story, Uncle Joe! :)
--
"His power lies apparently in his ability to choose incompetent
enemies." - Crow T. Robot, MST3K, "Prince of Space"
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
>
> >>>>> "Joe" == Joe Marshall <···@content-integrity.com> writes:
>
> Joe> It was *possible* to write malicious code that would do some
> Joe> entertaining things (a story for another time), but it wasn't
> Joe> often that a lisp process would bring down the entire machine
> Joe> when it caused an error.
>
> I'd love to hear about this. Actually, anything you have to say about
> the security model of the LispM would be interesting. I'm sure others
> here feel the same way. Tell us a story, Uncle Joe! :)
Well, I'm no Uncle Joe, but I have a story to share in this vein...
A novice came to me one time having crashed his machine by redefining the
function TIME, which is in a shared package that is used by the operating
system. He was in a break in the cold load stream with no remaining pointer
to the original definition of TIME even in the definitional undo place.
(Usually defun would store the old definition somewhere so you could undefun
in case of a bad error just such as this.) If I remember right, he'd defined
a struct with a slot that was named TIME and with no conc-name or something
like that and didn't realize this would have the cascade effect it did.
Anyway, it was surprisingly easy for him to topple the machine, and surprising
more people didn't do this, but it just didn't happen much. I decided we
should see if the definition of TIME was obvious. Rather than walk ten feet
to another LispM and look up the definition of TIME, I decided to wing it from
the paper doc at the guy's console. It told me that TIME returned an integer
the value of which was greater every second, and the base of which was not
defined. That didn't seem to hard to do. There was also a function
FIXNUM-MICROSECOND-TIME which seemed to do something related to that and
which I was betting was more primitive somehow. The return value of the
latter would roll over periodically so basing TIME's return value on this
looked to be dubious for the long haul in terms of monotonicity, but I
figured it wouldn't hurt while the guy saved his buffers. So I defined
(defun time () (* 1000000 (si:fixnum-microsecond-time)))
or some such thing [doing this from memory; my manuals are packed]
and told the debugger to proceed. The wholine immediately showed the console
had been idle four hundreds of years or something goofy like that, but the
system seemed to be running again. I told the guy to save his files as
quickly as possible and to reboot immediately thereafter.
I am not competent to revive a dead Microsoft box, so although a LispM had
indeed been easy to crash it was correspondingly easy to revive, and it made
me look very wizardly in a way I'd never been for, say, a pdp10 [mainframe;
the stock hardware of the time]. There's something really beautiful
about "Lisp all the way down".
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> writes:
> Anyway, it was surprisingly easy for him to topple the machine, and surprising
> more people didn't do this, but it just didn't happen much.
It probably did happen more often but we were too embarassed to let anyone
know. (Advising NTH isn't a good idea on a LispM!)
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: Security exploits on a LispM?
Date:
Message-ID: <ey38zocdyfn.fsf@cley.com>
* Mike McDonald wrote:
> It probably did happen more often but we were too embarassed to let anyone
> know. (Advising NTH isn't a good idea on a LispM!)
I remember trying to trace PRINT on a Xerox Dmachine. Something
happened towards the end which involved some weird little cascade of
half-formed windows, I think recursive entries into the debugger
before it really ran out of stack for good before the dreaded
mouse-cursor error-code.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Mike McDonald wrote:
>
> > It probably did happen more often but we were too embarassed to
> > let anyone know. (Advising NTH isn't a good idea on a LispM!)
>
> I remember trying to trace PRINT on a Xerox Dmachine. Something
> happened towards the end which involved some weird little cascade of
> half-formed windows, I think recursive entries into the debugger
> before it really ran out of stack for good before the dreaded
> mouse-cursor error-code.
By contrast:
The VAXLISP group at DEC was very proud that they made VAXLISP's TRACE
completely secure. It had its own private copy of everything the user
would know about so you could TRACE anything at all...
In article <····················@typhoon.aracnet.com>,
Mike McDonald <·······@mikemac.com> wrote:
>In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> writes:
>
>> Anyway, it was surprisingly easy for him to topple the machine, and surprising
>> more people didn't do this, but it just didn't happen much.
>
> It probably did happen more often but we were too embarassed to let anyone
>know. (Advising NTH isn't a good idea on a LispM!)
We once managed to change the value of NIL or T. SETQ checked for this and
rejected it, but SET didn't catch it at the time. It didn't take long for
the system to crash. I sure had fun tracing data structures in the FEP
debugger to find out what we'd done.
In the next release the value cells of constants were forwarded to
read-only memory pages, so that the hardware would catch it.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> We once managed to change the value of NIL or T. SETQ checked for this and
> rejected it, but SET didn't catch it at the time.
ISTR a story that SETQ printed cute Latin quotes if you tried to
change T or NIL, but I've lost the quotes. Does anyone have a working
LispM around to try?
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
In article <··············@localhost.localdomain>,
Lieven Marchand <···@village.uunet.be> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> We once managed to change the value of NIL or T. SETQ checked for this and
>> rejected it, but SET didn't catch it at the time.
>
>ISTR a story that SETQ printed cute Latin quotes if you tried to
>change T or NIL, but I've lost the quotes. Does anyone have a working
>LispM around to try?
It was something like:
Veritas aeterna - Don't SETQ T
Nihil est nihilem - Don't SETQ NIL
I'm pretty sure about the T line, but I don't think I have the NIL line
quite right. I believe they translate to "truth is eternal" and "nothing
is nothing".
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> Nihil est nihilem - Don't SETQ NIL
>
> I'm pretty sure about the T line, but I don't think I have the NIL line
> quite right. I believe they translate to "truth is eternal" and "nothing
> is nothing".
I thought the NIL version was something like EX NIHILE NIHIL or
NIHIL EX NIHILE ("nothing out of nothing"). But my Latin's very
rusty, so I may have the case ending wrong.
Arthur Lemmens
From: Dorai Sitaram
Subject: Re: Security exploits on a LispM?
Date:
Message-ID: <9447j7$21v$1@news.gte.com>
In article <·················@xs4all.nl>,
Arthur Lemmens <········@xs4all.nl> wrote:
>
>I thought the NIL version was something like EX NIHILE NIHIL or
>NIHIL EX NIHILE ("nothing out of nothing"). But my Latin's very
>rusty, so I may have the case ending wrong.
From what appears to be a verbatim MacLisp transcript on
p. 231 of Ian Mason's _The Semantics of Destructive
Lisp_, the phrases are
veritas aeterna - don't setq t
nihil ex nihil - don't setq nil
In article <············@news.gte.com>,
····@goldshoe.gte.com (Dorai Sitaram) wrote:
> In article <·················@xs4all.nl>,
> Arthur Lemmens <········@xs4all.nl> wrote:
> >
> >I thought the NIL version was something like EX NIHILE NIHIL or
> >NIHIL EX NIHILE ("nothing out of nothing"). But my Latin's very
> >rusty, so I may have the case ending wrong.
>
> From what appears to be a verbatim MacLisp transcript on
> p. 231 of Ian Mason's _The Semantics of Destructive
> Lisp_, the phrases are
>
> veritas aeterna - don't setq t
> nihil ex nihil - don't setq nil
I hate to start a language war :-), but shouldn't it be "nihil ex nihilo"
(nothing comes out of nothing)?
Who's the local Latin expert.
g
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
glauber <··········@my-deja.com> writes:
>
> I hate to start a language war :-), but shouldn't it be "nihil ex nihilo"
> (nothing comes out of nothing)?
>
> Who's the local Latin expert.
Well, I was going to stay out of this since my Latin-English
dictionary is at home, but since no one else is jumping in I'll wager
an opinion: ISTR, and a couple poor quality, online dictionaries
confirm, that nihil does not decline, so 'nihil ex nihil' would be
correct. There is also, IIRC, a form that does, 'nihilum'. If that
is true (and nihilum is regular 2nd declension), then 'nihil ex
nihilo' would also be correct.
I think.
Maybe.
Thom
--
Thom Goodsell ···@cra.com
Scientist (617) 491-3474 x574
Charles River Analytics http://www.cra.com/
In article <··············@shalott.cra.com>,
Thom Goodsell <···@cra.com> wrote:
> glauber <··········@my-deja.com> writes:
> >
> > I hate to start a language war :-), but shouldn't it be "nihil ex nihilo"
> > (nothing comes out of nothing)?
> >
> > Who's the local Latin expert.
>
> Well, I was going to stay out of this since my Latin-English
> dictionary is at home, but since no one else is jumping in I'll wager
> an opinion: ISTR, and a couple poor quality, online dictionaries
> confirm, that nihil does not decline, so 'nihil ex nihil' would be
> correct. There is also, IIRC, a form that does, 'nihilum'. If that
> is true (and nihilum is regular 2nd declension), then 'nihil ex
> nihilo' would also be correct.
It sounds right. I was born in Latin America, but my Latin is not that good.
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
glauber <··········@my-deja.com> writes:
> I hate to start a language war :-), but shouldn't it be "nihil ex nihilo"
> (nothing comes out of nothing)?
>
> Who's the local Latin expert.
I'm pretty sure that wording is due to Steele, who went to some Latin
school and has tended to inject little Latinisms into Lispiness over the
years. You should have seen the discussion that led to the introduction
of DECLAIM. (We also talked about the possibility of a "proclare". He
was happy that "declaim" works as an English word, mixing "declare" and
"proclaim".)
Boris Schaefer <·····@uncommon-sense.net> writes:
| Apparently, "nihil" (and "nil") exist only in the nominative and
| accusative cases. The other cases are constructed with the
| appropriate forms of "nullus res".
^^^^^^^^^^
Duh, that should have been "nulla res".
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
Conscious is when you are aware of something and conscience is when you
wish you weren't.
Arthur Lemmens <········@xs4all.nl> writes:
> Barry Margolin wrote:
>
> > Nihil est nihilem - Don't SETQ NIL
> >
> > I'm pretty sure about the T line, but I don't think I have the NIL line
> > quite right. I believe they translate to "truth is eternal" and "nothing
> > is nothing".
>
> I thought the NIL version was something like EX NIHILE NIHIL or
> NIHIL EX NIHILE ("nothing out of nothing"). But my Latin's very
> rusty, so I may have the case ending wrong.
Should be E NIHILO, although EX didn't always drop the X before a
consonant.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Barry Margolin <······@genuity.net> wrote:
> >ISTR a story that SETQ printed cute Latin quotes if you tried to
> >change T or NIL, but I've lost the quotes. Does anyone have a working
> >LispM around to try?
>
> It was something like:
>
> Veritas aeterna - Don't SETQ T
> Nihil est nihilem - Don't SETQ NIL
>
> I'm pretty sure about the T line, but I don't think I have the NIL line
> quite right. I believe they translate to "truth is eternal" and "nothing
> is nothing".
>
In CMUCL code/symbol.lisp:
(defun set (variable new-value)
"VARIABLE must evaluate to a symbol. This symbol's special value cell is
set to the specified new value."
(declare (type symbol variable))
(cond ((null variable)
(error "Nihil ex nihil, can't set NIL."))
((eq variable t)
(error "Veritas aeterna, can't set T."))
((and (boundp '*keyword-package*)
(keywordp variable))
(error "Can't set keywords."))
(t
(%set-symbol-value variable new-value))))
--
Arnaud Rouanet
Arnaud Rouanet <·······@emi.u-bordeaux.fr> writes:
> Barry Margolin <······@genuity.net> wrote:
>
> > >ISTR a story that SETQ printed cute Latin quotes if you tried to
> > >change T or NIL, but I've lost the quotes. Does anyone have a working
> > >LispM around to try?
> >
> > It was something like:
> >
> > Veritas aeterna - Don't SETQ T
> > Nihil est nihilem - Don't SETQ NIL
> >
> > I'm pretty sure about the T line, but I don't think I have the NIL line
> > quite right. I believe they translate to "truth is eternal" and "nothing
> > is nothing".
> >
>
> In CMUCL code/symbol.lisp:
>
> (defun set (variable new-value)
> "VARIABLE must evaluate to a symbol. This symbol's special value cell is
> set to the specified new value."
> (declare (type symbol variable))
> (cond ((null variable)
> (error "Nihil ex nihil, can't set NIL."))
> ((eq variable t)
> (error "Veritas aeterna, can't set T."))
> ((and (boundp '*keyword-package*)
> (keywordp variable))
> (error "Can't set keywords."))
Someone might correct my spelling, but the old maclisp error message for
this should be:
PURITAS NESSESE ES - DON'T DO RANDOM BINDINGS
I'm sure I can find the actual spelling if anyone cares. Anyone with a copy
of the file "COMMON;LINS >" from one of the ITS machines can probably also
find it in there, since the phrase was kept there for the "bye lines".
It occurred whenever a symbol other than NIL or T but treated the same
as that (which had to be created by the programmer manually using PURCOPY,
I think) had someone try to modify its value cell.
Except for +INTERNAL-WITHOUT-INTERRUPTS. But that was seriously weird
magic and is another story.
> (t
> (%set-symbol-value variable new-value))))
>
> --
> Arnaud Rouanet
Kent M Pitman <······@world.std.com> writes:
> Someone might correct my spelling, but the old maclisp error message for
> this should be:
>
> PURITAS NESSESE ES - DON'T DO RANDOM BINDINGS
>
PVRITAS NECCESSE EST.
The above looks like a phonetic reproduction from someone who learned
medieval church latin in stead of Erasmus' pronunciation.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
On Wed, 17 Jan 2001 16:19:15 GMT, Kent M Pitman <······@world.std.com>
wrote:
> Someone might correct my spelling, but the old maclisp error message for
> this should be:
>
> PURITAS NESSESE ES - DON'T DO RANDOM BINDINGS
Maybe "necesse est" ("it is necessary", i.e. "purity is necessary)?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> I'd love to hear about ... the security model of the LispM.
Stupid Lisp Machine Trick number 1:
The Lisp Machine did not usually run many server processes. It is
tricky to break into a machine that isn't listening to the nework.
However, most LispM's ran a band-copy server. This would allow you to
copy a world image from one LispM to another. It turns out that
whoever coded this server used READ to get the band name, so
requesting a band name of
#.(progn (do-something-malicious) 'no-such-band)
would do the trick.
For some unfathomable reason, the bitmap video of the LispM didn't
use a counter to step through memory to find the bits. Each physical
line on the screen was mapped via a RAM to a logical line in memory.
Usually, this RAM was loaded with ascending values at boot time and
never touched afterwards, but you could flip the screen over by simply
rewriting it with descending values. (For the extra hack value, you
can compute the width of the wholine and leave it at the bottom of the
screen.)
Unfortunately, the pool of `victims' for this was rather limited.
On the other hand, I guess we were more easily amused back then.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Barry Margolin
Subject: Re: Did Lisp machines provide GC for kernel-level code?
Date:
Message-ID: <eTF76.48$IL1.438@burlma1-snr2>
In article <··············@soyuz.arslogica.com>,
Kaelin Colclasure <······@everest.com> wrote:
>Rainer Joswig <······@corporate-world.lisp.de> writes:
>
>[...]
>> If it is written in Lisp (almost everything is), it will
>> have to use one or more of the memory management strategies.
>> Networking code uses for example "wired" packets. The
>> system makes extensive use of manual memory management.
>
>Are you referring here to "resources-style" manual memory management,
>or explicit deallocation? It would be interesting to see just how
>much of the low-level code was deemed to need manual memory management.
It was resources-style memory management. It was mostly used by device and
network drivers to ensure that they could allocate and free I/O buffers at
interrupt speed.
>> Also remember that there is not really much of "kernel
>> modules" and "device drivers" - most stuff is just
>> a type (foreground, background, deadline)
>> of Lisp thread (even the mouse has it's own thread)
>> with a certain priority. All is running
>> in one big multi-threaded Lisp image.
>
>Hmmm, are there no privilege rings? I suppose at the time this might
>have been deemed unnecessary for what was primarily a single-user
>system?
Yes, they were designed as single-user workstations, much like Windows and
MacOS. Calls to the "kernel" are just ordinary Lisp calls.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kaelin Colclasure <······@everest.com> writes:
> Just an idle curiosity -- but did Lisp machines provide garbage
> collection at the level of kernel modules and device drivers?
What do you mean?
GC was part microcode, part lisp code.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----