Hi
Are there computers optimized for Lisp still in mass production? By
the way, back when they first Lisp Machines first appeared, where they
really providing considerable optimizations?
A.
Alex Braun wrote:
> Are there computers optimized for Lisp still in mass production?
IIRC up until very recently SUN -- in pre-sparc III processors -- had
a number of instructions that were designed to help with making
efficient Lisp based gc.
:)w
>> Are there computers optimized for Lisp still in mass production?
> IIRC up until very recently SUN -- in pre-sparc III processors -- had
> a number of instructions that were designed to help with making
> efficient Lisp based gc.
You say "up until very recently"... Is the converse the case, ie, did
they stop? I'd figure with the Great Java Push that gc instructions
would still be non-reclaimable!
Cheers,
joelh
Joel Ray Holveck wrote:
> You say "up until very recently"... Is the converse the case, ie, did
> they stop? I'd figure with the Great Java Push that gc instructions
> would still be non-reclaimable!
I think he may be refering to the special arithmetic instructions
that check the two low order bits (and detect overflow too?).
These instructions allow general Lisp integer arithmetic to be
inlined so that bignums are still handled, but the common case
of fixnum arithmetic is still fast.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Joel Ray Holveck wrote:
>
> > You say "up until very recently"... Is the converse the case, ie, did
> > they stop? I'd figure with the Great Java Push that gc instructions
> > would still be non-reclaimable!
>
> I think he may be refering to the special arithmetic instructions
> that check the two low order bits (and detect overflow too?).
Yes, TADDCC checks both the two low-order bits and the 32-bit overflow
so that both non-fixnum adds and fixnum+fixnum->bignum can be detected
inline.
> These instructions allow general Lisp integer arithmetic to be
> inlined so that bignums are still handled, but the common case
> of fixnum arithmetic is still fast.
Yes.
The problems with this instruction are that it has been deprecated for
the sparcv9 and later architectures, and it only works for 32-bit lisps
because it does not set the 64-bit overflow result. So "up until very
recently" could mean until 64-bit lisp on Sparc.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>"Paul F. Dietz" <·····@dls.net> writes:
>
>> Joel Ray Holveck wrote:
>>
>> > You say "up until very recently"... Is the converse the case, ie, did
>> > they stop? I'd figure with the Great Java Push that gc instructions
>> > would still be non-reclaimable!
>>
>> I think he may be refering to the special arithmetic instructions
>> that check the two low order bits (and detect overflow too?).
>
>Yes, TADDCC checks both the two low-order bits and the 32-bit overflow
>so that both non-fixnum adds and fixnum+fixnum->bignum can be detected
>inline.
In any case, I think it takes more than one Lisp-specific instruction to
turn something into a Lisp Machine, unless it's an EVAL instruction (didn't
the MIT Scheme chip have something like that?).
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
> >"Paul F. Dietz" <·····@dls.net> writes:
> >
> >> Joel Ray Holveck wrote:
> >>
> >> > You say "up until very recently"... Is the converse the case, ie, did
> >> > they stop? I'd figure with the Great Java Push that gc instructions
> >> > would still be non-reclaimable!
> >>
> >> I think he may be refering to the special arithmetic instructions
> >> that check the two low order bits (and detect overflow too?).
> >
> >Yes, TADDCC checks both the two low-order bits and the 32-bit overflow
> >so that both non-fixnum adds and fixnum+fixnum->bignum can be detected
> >inline.
>
> In any case, I think it takes more than one Lisp-specific instruction to
> turn something into a Lisp Machine [ ... ]
I agree. However, as a proponent of Lisp-on-GP-hardware, I don't
consider this to be a Bad Thing. I prefer using those features that
General Purpose computers have to offer to implement Lisp in as many
efficient ways as possible, so that we can best ride the Moore's Law
wave.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> "Paul F. Dietz" <·····@dls.net> writes:
>> Joel Ray Holveck wrote:
>>
>> > You say "up until very recently"... Is the converse the case, ie, did
>> > they stop? I'd figure with the Great Java Push that gc instructions
>> > would still be non-reclaimable!
>>
>> I think he may be refering to the special arithmetic instructions
>> that check the two low order bits (and detect overflow too?).
Duane> Yes, TADDCC checks both the two low-order bits and the 32-bit overflow
Duane> so that both non-fixnum adds and fixnum+fixnum->bignum can be detected
Duane> inline.
>> These instructions allow general Lisp integer arithmetic to be
>> inlined so that bignums are still handled, but the common case
>> of fixnum arithmetic is still fast.
Duane> Yes.
Duane> The problems with this instruction are that it has been deprecated for
Duane> the sparcv9 and later architectures, and it only works for 32-bit lisps
Only the trapping version is deprecated. The none trapping version is
still there.
Duane> because it does not set the 64-bit overflow result. So "up until very
Duane> recently" could mean until 64-bit lisp on Sparc.
In addition, I think it only checks the 2 lowest bits. For a 64-bit
Lisp, you probably want the 3 lowest bits. But a 64-bit lisp probably
also has 4 bits for tags, so it's not so bad to use up 4 of them to
represent fixnums.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
>
> Duane> "Paul F. Dietz" <·····@dls.net> writes:
> >> Joel Ray Holveck wrote:
> >>
> >> > You say "up until very recently"... Is the converse the case, ie, did
> >> > they stop? I'd figure with the Great Java Push that gc instructions
> >> > would still be non-reclaimable!
> >>
> >> I think he may be refering to the special arithmetic instructions
> >> that check the two low order bits (and detect overflow too?).
>
> Duane> Yes, TADDCC checks both the two low-order bits and the 32-bit overflow
> Duane> so that both non-fixnum adds and fixnum+fixnum->bignum can be detected
> Duane> inline.
>
> >> These instructions allow general Lisp integer arithmetic to be
> >> inlined so that bignums are still handled, but the common case
> >> of fixnum arithmetic is still fast.
>
> Duane> Yes.
>
> Duane> The problems with this instruction are that it has been deprecated for
> Duane> the sparcv9 and later architectures, and it only works for 32-bit lisps
>
> Only the trapping version is deprecated. The none trapping version is
> still there.
OK, I believe you; that rings true in my memory, and I don't have my Sparc V9
manual handy now or when I wrote this. I take back what I said about it being
deprecated (the taddcctv instruction, as I recall, is deprecated, which we
also use as a conditional-trapping mechanism for signal synchronization).
However, the fact or fiction of taddcc being deprecated is irrelevant to
it being unsuitable for 64-bit ports.
> Duane> because it does not set the 64-bit overflow result. So "up until very
> Duane> recently" could mean until 64-bit lisp on Sparc.
>
> In addition, I think it only checks the 2 lowest bits. For a 64-bit
> Lisp, you probably want the 3 lowest bits. But a 64-bit lisp probably
> also has 4 bits for tags,
Checking the two lowest bits is still not a problem, if you don't define any
multiple-of-4 tags for anything. If you define tag 0 as even-fixnum, 8 as
odd-fixnum, and 4 and #xc as nothing, then the taddcc would have worked,
except for its incorrect (*) treatment of overflows.
> so it's not so bad to use up 4 of them to
> represent fixnums.
I'm not sure whether you meant "4 tag values" or "4 bits" here. For tags
in general, 4 bits is a good number to use, because that gives you
a 16-byte Allocation Unit, where you have 8 byte AUs in 32 bit lisps.
For fixnums, you can go with either 4 bits (using one tag value, probably
0), 3 bits (using 0 for even fixnums and 8 for odd fixnums) or 2 bits
(using up 4 tag values to define fixnums). There are pros for using 2 and
3 bits, but I don't know of any pros for using 4 bits (4 bits of tag gives
you less immediate data to work with). The major plus for 2 bit tags is
that it doubles the fixnum range. However, this plus is offset by the fact
that it does not cover the entire machine-integer range, and so is not
as useful as one might expect. The major plus for using 3 bits of fixnum
tags is that array references for all natural-sized arrays remain shift-free
(e.g. the instruction-level implementation of
(aref (the simple-vector x) 100)
contains no shift instruction). We settled on that number for our fixnum
implementation. This is also consistent with our 32-bit ports, which also
use 2 tag values in order to provide 2-bit fixnum tags in a 3-bit taggng
system (and which also thus allow for simple-vector access with no shifting).
(*) "incorrect" is not the right term here, though I use it for emphasis.
That the spec says what it says makes what taddcc does correct by
definition. However, the spec is itself inconsistent in that most V9
instructions set two condition registers, the %icc (32-bit) and the
%xcc (64-bit) conditions. The conditional branches can then test either
condition set, and that is what makes the distinction between 32 and 64 bit
operation. However, the taddcc (and tsubcc) instructions set only the
32-bit overflow when the lsbits are non-zero.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
>>>>> "Duane" == Duane Rettig <·····@franz.com> writes:
Duane> Raymond Toy <···@rtp.ericsson.se> writes:
Duane> The problems with this instruction are that it has been deprecated for
Duane> the sparcv9 and later architectures, and it only works for 32-bit lisps
>>
>> Only the trapping version is deprecated. The none trapping version is
>> still there.
Duane> OK, I believe you; that rings true in my memory, and I don't have my Sparc V9
Duane> manual handy now or when I wrote this. I take back what I said about it being
Duane> deprecated (the taddcctv instruction, as I recall, is deprecated, which we
Duane> also use as a conditional-trapping mechanism for signal synchronization).
Duane> However, the fact or fiction of taddcc being deprecated is irrelevant to
Duane> it being unsuitable for 64-bit ports.
Sorry, I didn't mean to imply you were wrong. As you say, taddcc is still
unsuitable.
Duane> because it does not set the 64-bit overflow result. So "up until very
Duane> recently" could mean until 64-bit lisp on Sparc.
>>
>> In addition, I think it only checks the 2 lowest bits. For a 64-bit
>> Lisp, you probably want the 3 lowest bits. But a 64-bit lisp probably
>> also has 4 bits for tags,
Duane> Checking the two lowest bits is still not a problem, if you don't define any
Duane> multiple-of-4 tags for anything. If you define tag 0 as even-fixnum, 8 as
Duane> odd-fixnum, and 4 and #xc as nothing, then the taddcc would have worked,
Duane> except for its incorrect (*) treatment of overflows.
Didn't think about that. Since I've never seriously tried
implementing a 64-bit lisp, I was just thinking out loud.
>> so it's not so bad to use up 4 of them to
>> represent fixnums.
[snip]
Duane> as useful as one might expect. The major plus for using 3 bits of fixnum
Duane> tags is that array references for all natural-sized arrays remain shift-free
Duane> (e.g. the instruction-level implementation of
Duane> (aref (the simple-vector x) 100)
Duane> contains no shift instruction). We settled on that number for our fixnum
Duane> implementation. This is also consistent with our 32-bit ports, which also
Duane> use 2 tag values in order to provide 2-bit fixnum tags in a 3-bit taggng
Duane> system (and which also thus allow for simple-vector access with no shifting).
Yes, this was my thinking of using 3 bits for fixnum tags.
Duane> (*) "incorrect" is not the right term here, though I use it for emphasis.
Duane> That the spec says what it says makes what taddcc does correct by
Duane> definition. However, the spec is itself inconsistent in that most V9
Duane> instructions set two condition registers, the %icc (32-bit) and the
Duane> %xcc (64-bit) conditions. The conditional branches can then test either
Duane> condition set, and that is what makes the distinction between 32 and 64 bit
Duane> operation. However, the taddcc (and tsubcc) instructions set only the
Duane> 32-bit overflow when the lsbits are non-zero.
I wonder why they did that. It seems natural to do the same thing.
Oh well. I think the Sparc architecture will die (sadly) in a few
years anyway.
Ray
Duane Rettig <·····@franz.com> writes:
> The problems with [TADDCC] are that it has been deprecated for the
> sparcv9 and later architectures
As far as I can see in the UltraSPARC User's Manual (July 1997
edition, covers UltraSPARC-I and UltraSPARC-II), TADDcc(TV) and
TSUBcc(TV) are all implemented and indicated as V9 instructions.
From chapter 12, Instruction Set Summary:
The UltraSPARC CPU implements both the standard SPARC-V9 instruction
set and a number of implementation-dependent extended instructions.
[...]
Table 12-1 lists the complete UltraSPARC instruction set. A check
([check]) in the "Ext" column indicates that the instruction is an
UltraSPARC extension; the absence of a check indicates a SPARC-V9
core instruction. [...]
Table 12-1 Complete UltraSPARC instruction Set
Opcode Description Ext Ref
[...]
TADDcc Tagged add and modify condition codes
(TADDccTV) (trap on overflow)
TSUBcc Tagged subtract and modify condition
(TSUBccTV) codes (trap on overflow)
>>>>> "Lars" == Lars Brinkhoff <·········@nocrew.org> writes:
Lars> Duane Rettig <·····@franz.com> writes:
>> The problems with [TADDCC] are that it has been deprecated for the
>> sparcv9 and later architectures
Lars> As far as I can see in the UltraSPARC User's Manual (July 1997
Lars> edition, covers UltraSPARC-I and UltraSPARC-II), TADDcc(TV) and
Lars> TSUBcc(TV) are all implemented and indicated as V9 instructions.
Yes, they are implemented. My Sparc Architecture Manual says the
taddcctv and tsubcctv instructions are deprecated and are there just
for backward compatibility.
Ray
Lars Brinkhoff <·········@nocrew.org> writes:
> Duane Rettig <·····@franz.com> writes:
> > The problems with [TADDCC] are that it has been deprecated for the
> > sparcv9 and later architectures
> As far as I can see in the UltraSPARC User's Manual (July 1997
> edition, covers UltraSPARC-I and UltraSPARC-II), TADDcc(TV) and
> TSUBcc(TV) are all implemented and indicated as V9 instructions.
Ok, I see now in the SPARC Architecture Manual V9 that TADDccTV and
TSUBccTV have been deprecated. However, TADDcc and TSUBcc are still
there.
"Alex Braun" <······@cyberspace.org> wrote in message ································@posting.google.com...
> Hi
>
> Are there computers optimized for Lisp still in mass production?
No. (Were they ever? I don't think more than 10,000 machines
were ever built by all manufacturers combined, but I don't have
concrete numbers, just speculation from various sources.)
> By
> the way, back when they first Lisp Machines first appeared, where they
> really providing considerable optimizations?
When they were first built, yes. But raw performance wasn't the
only advantage. There were many things that you simply cannot do
on stock hardware without emulating the LispM hardware. For instance,
hot-patching the microcode and adding machine instructions.
Since the LispM OS was written in Lisp and shared the address space
with user code, it was easy to modify the OS. Integrating the
paging system with the garbage collector was one of these. (Only
fairly recent OSs seem to have support for user programs advising
the OS about paging policy.)
Even these days a custom lisp machine could significantly outperform
stock hardware, but performance is not even the primary driving
force in the market.
······@cyberspace.org (Alex Braun) writes:
> Hi
>
> Are there computers optimized for Lisp still in mass production ?
No, but you can buy OpenGenera, which emulates a Lisp Machine
architecture for Alpha processors.