Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2513 > unrolled thread

Architecture / Instruction Set / Language co-design.

Back to article view | Back to comp.arch

Contents

  Architecture / Instruction Set / Language co-design. Roberto Waltman <usenet@rwaltman.com> - 2011-07-14 15:37 -0400
    Re: Architecture / Instruction Set / Language co-design. blp@cs.stanford.edu (Ben Pfaff) - 2011-07-14 13:03 -0700
      Re: Architecture / Instruction Set / Language co-design. Peter Flass <Peter_Flass@Yahoo.com> - 2011-07-14 21:16 -0400
    Re: Architecture / Instruction Set / Language co-design. Peter Flass <Peter_Flass@Yahoo.com> - 2011-07-14 16:06 -0400
      Re: Architecture / Instruction Set / Language co-design. Charles Richmond <frizzle@tx.rr.com> - 2011-07-14 20:42 -0500
        Re: Architecture / Instruction Set / Language co-design. Peter Flass <Peter_Flass@Yahoo.com> - 2011-07-15 07:50 -0400
          Re: Architecture / Instruction Set / Language co-design. Anne & Lynn Wheeler <lynn@garlic.com> - 2011-07-15 09:56 -0400
          Re: Architecture / Instruction Set / Language co-design. John Levine <johnl@iecc.com> - 2011-07-15 17:38 +0000
            Re: Architecture / Instruction Set / Language co-design. Charles Richmond <frizzle@tx.rr.com> - 2011-07-15 23:22 -0500
              Re: Architecture / Instruction Set / Language co-design. John Levine <johnl@iecc.com> - 2011-07-17 19:33 +0000
    Re: Architecture / Instruction Set / Language co-design. cb@mer.df.lth.se (Christian Brunschen) - 2011-07-14 20:25 +0000
    Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-14 17:42 -0400
      Re: Architecture / Instruction Set / Language co-design. mac <acolvin@efunct.com> - 2011-07-17 15:31 +0000
        Re: Architecture / Instruction Set / Language co-design. Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-17 16:59 +0100
        Re: Architecture / Instruction Set / Language co-design. Anne & Lynn Wheeler <lynn@garlic.com> - 2011-07-17 12:11 -0400
          Re: Architecture / Instruction Set / Language co-design. Mike Hore <mike_horeREM@OVE.invalid.aapt.net.au> - 2011-07-19 12:04 +1000
        Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-17 13:02 -0400
          Re: Architecture / Instruction Set / Language co-design. Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-07-17 20:42 +0200
            Re: Architecture / Instruction Set / Language co-design. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-18 11:49 +0000
          Re: Architecture / Instruction Set / Language co-design. Andrew Reilly <areilly---@bigpond.net.au> - 2011-07-17 23:14 +0000
            Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-19 12:54 -0400
              Re: Architecture / Instruction Set / Language co-design. Andrew Reilly <areilly---@bigpond.net.au> - 2011-07-19 22:16 +0000
        Re: Architecture / Instruction Set / Language co-design. Roberto Waltman <usenet@rwaltman.com> - 2011-07-17 19:20 -0400
          Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-19 12:54 -0400
            Re: Architecture / Instruction Set / Language co-design. Roberto Waltman <usenet@rwaltman.com> - 2011-07-19 14:50 -0400
          Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-19 16:24 -0400
    Re: Architecture / Instruction Set / Language co-design. Andrew Reilly <areilly---@bigpond.net.au> - 2011-07-14 22:57 +0000
      Re: Architecture / Instruction Set / Language co-design. Michael S <already5chosen@yahoo.com> - 2011-07-19 16:16 -0700
    Re: Architecture / Instruction Set / Language co-design. EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-14 19:04 -0400
    Re: Architecture / Instruction Set / Language co-design. Al Kossow <aek@bitsavers.org> - 2011-07-14 17:15 -0700
    Re: Architecture / Instruction Set / Language co-design. Robert Wessel <robertwessel2@yahoo.com> - 2011-07-14 20:34 -0500
    Re: Architecture / Instruction Set / Language co-design. torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-07-15 10:28 +0200
    Re: Architecture / Instruction Set / Language co-design. kenney@cix.compulink.co.uk - 2011-07-15 04:31 -0500
    Re: Architecture / Instruction Set / Language co-design. Mark Thorson <nospam@sonic.net> - 2011-07-18 14:26 -0800
      Re: Architecture / Instruction Set / Language co-design. Charles Richmond <plano.net@aquaporin4.com> - 2011-07-20 01:10 -0500

Page 2 of 2 — ← Prev page 1 [2]

#2595

Andrew Reilly wrote:
> On Sun, 17 Jul 2011 13:02:25 -0400, EricP wrote:
> 
>> The LISP machine had to run an OS in addition to LISP which means it has
>> to do everything other cpus do.
> 
> It depends on which LISP machine you're talking about, but I believe that 
> in the case of things like the Symbolics and Explorer systems, that's not 
> true: it was lisp all the way down to a kernel written in machine code 
> and compiled by the same lisp compiler as the rest of the system.  Since 
> these lisp systems operated on a holistic stored memory image model 
> you're only a couple of reboots away from self hosting.  Also, they 
> tended to be single-user systems without hardware memory protection (the 
> LISP type system caught stray accesses).
> 
> So, while the LISP machines did have (actually, "were") an OS, and did 
> all of the interrupt handling and device driving that other CPUs do, they 
> didn't do it by running on top of Unix or whatever.  Somewhat like '80's 
> vintage BASIC PCs in that regard.
> 
> Cheers,
> 

Ok, but what I was questioning is was there anything special
about the hardware that allowed those machines a stronger
claim to being designed for a particular language
than any other system with a marketting document?

Looking at the wikipedia article
http://en.wikipedia.org/wiki/Lisp_machine

it seems that their claim is more than marketting as it talks about,
in the Lisp Machine Project, memory words being extended from
32 bits to first 36 then later 40 bits to hold the data type tags.
Also having instructions that understood those tags.

Eric

[toc] | [prev] | [next] | [standalone]

#2601

On Tue, 19 Jul 2011 12:54:47 -0400, EricP wrote:
> Ok, but what I was questioning is was there anything special about the
> hardware that allowed those machines a stronger claim to being designed
> for a particular language than any other system with a marketting
> document?
> 
> Looking at the wikipedia article
> http://en.wikipedia.org/wiki/Lisp_machine
> 
> it seems that their claim is more than marketting as it talks about, in
> the Lisp Machine Project, memory words being extended from 32 bits to
> first 36 then later 40 bits to hold the data type tags. Also having
> instructions that understood those tags.

Oh, I didn't think that there was any doubt about that.  Sorry for 
misunderstanding.  Tagged memory was probably the big difference, but 
they were definitely designed with the sole purpose of running their 
particular flavour of Lisp.

Cheers,

-- 
Andrew

[toc] | [prev] | [next] | [standalone]

#2567

mac wrote:
>> The Intel iAPX 432 was marketed as a processor for Ada
>
>Marketing it that way didn't make it so. I can't find my copy of Organick's
>book, but I remember at the time that this seemed bogus.

I was lucky enough to have access to some of the 432's documentation
around the time it was announced, via a friend that worked for Intel.
(He didn't work on this, but was very excited with the project)
Don't remember much today, but even with my (very) limited knowledge
and experience at the time, I do remember thinking there was nothing
ADA specific in the design. 
A couple of intriguing concepts were that you could add processors to
a system transparently, and memory addressable at the bit level.
The "designed to run ADA" claim was probably in line with the concept
that, at that time, if you have any thing ADAish some government money
may be coming (indirectly) your way.

> I heard that elements of the design wound up in the 286 et seq.
That's what oral tradition tells us. (Segmented memory, segment based
protection, call gates...)
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#2594

Roberto Waltman wrote:
> mac wrote:
>>> The Intel iAPX 432 was marketed as a processor for Ada
>> Marketing it that way didn't make it so. I can't find my copy of Organick's
>> book, but I remember at the time that this seemed bogus.
> 
> I was lucky enough to have access to some of the 432's documentation
> around the time it was announced, via a friend that worked for Intel.
> (He didn't work on this, but was very excited with the project)
> Don't remember much today, but even with my (very) limited knowledge
> and experience at the time, I do remember thinking there was nothing
> ADA specific in the design. 
> A couple of intriguing concepts were that you could add processors to
> a system transparently, and memory addressable at the bit level.
> The "designed to run ADA" claim was probably in line with the concept
> that, at that time, if you have any thing ADAish some government money
> may be coming (indirectly) your way.
> 
>> I heard that elements of the design wound up in the 286 et seq.
> That's what oral tradition tells us. (Segmented memory, segment based
> protection, call gates...)
> --
> Roberto Waltman
> 
> [ Please reply to the group.
>   Return address is invalid ]

The book Capability-based Computer Systems (1984)
is available from the author online.
Chapter 9 covers technical design of iAPX 432
http://www.cs.washington.edu/homes/levy/capabook/

Eric

[toc] | [prev] | [next] | [standalone]

#2598

 EricP wrote:
>The book Capability-based Computer Systems (1984)
>is available from the author online.
>http://www.cs.washington.edu/homes/levy/capabook/

Thanks for that. I spent a lot of time searching for a printed copy
years ago, finally giving up.
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#2599

Roberto Waltman wrote:
> 
> I was lucky enough to have access to some of the 432's documentation
> around the time it was announced, via a friend that worked for Intel.
> (He didn't work on this, but was very excited with the project)
> Don't remember much today, but even with my (very) limited knowledge
> and experience at the time, I do remember thinking there was nothing
> ADA specific in the design. 
> A couple of intriguing concepts were that you could add processors to
> a system transparently, and memory addressable at the bit level.
> The "designed to run ADA" claim was probably in line with the concept
> that, at that time, if you have any thing ADAish some government money
> may be coming (indirectly) your way.
> 
>> I heard that elements of the design wound up in the 286 et seq.
> That's what oral tradition tells us. (Segmented memory, segment based
> protection, call gates...)

I just found this:

Performance effects of architectural complexity in the intel 432 (1988)
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.140.5969


Eric

[toc] | [prev] | [next] | [standalone]

#2518

On Thu, 14 Jul 2011 15:37:53 -0400, Roberto Waltman wrote:

> Recently I've become (very) interested in Wirth's Lilith/Modula-2
> workstation, which leads me to ask:
> 
> What other systems were developed in a similar fashion?
> 
> That is, to support mainly one language with the language guiding the
> architectural design.

Bit of a stretch, perhaps: the AS-400 series of minis vs ?Cobol? ?PL/1?

The call/return instructions in the x86 series (and Vax?) are arguably 
good for Pascal and Algol-heratige languages and mostly get bypassed by C-
derived languages with variable-arity functions.

I think that you'll find that the Xerox Alto was part of a writeable-
microcode family that could be targeted to different language-specific 
instruction sets, and the one that was good for Smalltalk was only one 
variation.

Cheers,

-- 
Andrew

[toc] | [prev] | [next] | [standalone]

#2666

On Jul 15, 1:57 am, Andrew Reilly <areilly...@bigpond.net.au> wrote:
> On Thu, 14 Jul 2011 15:37:53 -0400, Roberto Waltman wrote:
> > Recently I've become (very) interested in Wirth's Lilith/Modula-2
> > workstation, which leads me to ask:
>
> > What other systems were developed in a similar fashion?
>
> > That is, to support mainly one language with the language guiding the
> > architectural design.
>
> Bit of a stretch, perhaps: the AS-400 series of minis vs ?Cobol? ?PL/1?
>

RPG.
Never touched AS/400 myself. From what I heard from friends back in
early 90s, RPG was considered the HLL of choice on this machines.

[toc] | [prev] | [next] | [standalone]

#2519

Roberto Waltman wrote:
> Recently I've become (very) interested in Wirth's Lilith/Modula-2
> workstation, which leads me to ask:
> 
> What other systems were developed in a similar fashion?
> 
> That is, to support mainly one language with the language guiding the
> architectural design.
> 
> My short list:
>    Lilith + Modula-2
>    LISP machines + LISP, of course
>    Burroughs B5000 + Algol's
>    The various Forth processors,
>    Transputers + Occam,
>    Xerox Alto?
> 
> Not sure about the last  - Thought the Alto fit into this category,
> but a memo from Butler Lampson suggests it had a conventional
> architecture:  "A processor which executes Nova instructions at about
> 1.5 us/instruction, and can be extended with extra instructions
> suitable for interpreting Lisp, Bcpl, MPS, or whatever."
> ( http://www.digibarn.com/friends/butler-lampson/index.html )
> 
> There is Rodnay Zaks book on a microprogrammed APL, but I couldn't
> find any reference to a Meta-4 actually running it.
> 
> Any more?
> 
> 
> 
> --
> Roberto Waltman
> 
> [ Please reply to the group.
>   Return address is invalid ]

Back in the early 1980's when boutique specialty processors
were all the rage some company did a presentation for
us for a microcoded bit-slice cpu designed to run sql.
I can't remember their name though - maybe someone else can.

Eric

[toc] | [prev] | [next] | [standalone]

#2521

On 7/14/11 12:37 PM, Roberto Waltman wrote:

>     Xerox Alto?
>

Alto was a microcoded machine that had several instruction sets implemented
on it. Similar to the Nanodata QM-1, Stanford EMMY and Meta 4.
The later Xerox Dorado was better tuned for executing byte-coded instruction
sets.
The Pascal Microengine used a Western Digital WD-16 processor with a P-code interpreter.

> There is Rodnay Zaks book on a microprogrammed APL, but I couldn't
> find any reference to a Meta-4 actually running it.
>

I have been told it was only ever a paper design. Paul McJones' APL actually
ran on a Meta-4.

[toc] | [prev] | [next] | [standalone]

#2525

On Thu, 14 Jul 2011 15:37:53 -0400, Roberto Waltman
<usenet@rwaltman.com> wrote:

>
>Recently I've become (very) interested in Wirth's Lilith/Modula-2
>workstation, which leads me to ask:
>
>What other systems were developed in a similar fashion?
>
>That is, to support mainly one language with the language guiding the
>architectural design.
>
>My short list:
>   Lilith + Modula-2
>   LISP machines + LISP, of course
>   Burroughs B5000 + Algol's
>   The various Forth processors,
>   Transputers + Occam,
>   Xerox Alto?
>
>Not sure about the last  - Thought the Alto fit into this category,
>but a memo from Butler Lampson suggests it had a conventional
>architecture:  "A processor which executes Nova instructions at about
>1.5 us/instruction, and can be extended with extra instructions
>suitable for interpreting Lisp, Bcpl, MPS, or whatever."
>( http://www.digibarn.com/friends/butler-lampson/index.html )
>
>There is Rodnay Zaks book on a microprogrammed APL, but I couldn't
>find any reference to a Meta-4 actually running it.


The Western Digital Pascal MicroEngine was specifically designed to
run Pascal via the UCSD p-system.  You might also consider the whole
RISC concept as revolving around *compiler* and ISA co-design,
particularly in its early days.

[toc] | [prev] | [next] | [standalone]

#2528

Roberto Waltman <usenet@rwaltman.com> writes:

> Recently I've become (very) interested in Wirth's Lilith/Modula-2
> workstation, which leads me to ask:
>
> What other systems were developed in a similar fashion?
>
> That is, to support mainly one language with the language guiding the
> architectural design.

The Three Rivers/ICL PERQ had a processor that was microcoded for p-code
(Pascal).

In the Japanese 5th generation project, a few Prolog machines were
developed.

Like LISP machines, these projects eventually failed because they
couldn't compete with stock hardware and improved compilers.  But I
think we in the future may see more languages designed for specific
hardware instead of the other way around: With increased parallelism,
all current mainstream languages are ill fits for future hardware
(though you can get some way by relying on libraries for parallelism),
so I expect we will see languages specifically designed to exploit
massive parallelism on architectures similar to GPGPUs.  These will look
more like APL than like C++ or Java.

	Torben

[toc] | [prev] | [next] | [standalone]

#2530

In article <vbhu17tqe8f03a9i8tar3kpoirg02l8iuj@4ax.com>, 
usenet@rwaltman.com (Roberto Waltman) wrote:

> That is, to support mainly one language with the language guiding the
> architectural design.

 There have been dedicated Lisp and Forth machines in fact the Green 
Array multiprocessor chip is designed for programming in "Colour Forth". 

 Ken Young

[toc] | [prev] | [next] | [standalone]

#2590

Roberto Waltman wrote:
>
> Recently I've become (very) interested in Wirth's Lilith/Modula-2
> workstation, which leads me to ask:
>
> What other systems were developed in a similar fashion?
>
> That is, to support mainly one language with the language guiding the
> architectural design.

It could be argued that the National Semiconductor NS16032 (later
renamed NS32016) qualifies.  The designers Les Kohn and Dan O'Dowd
started with an instruction set more-or-less based on the VAX and
pared it down to what they considered a minimum.  Dan wrote a Pascal
compiler that guided the design of the architecture in the sense that
every time the chip designers in Israel asked whether they could
delete a feature Les would turn to Dan and ask how that would affect
the compiler.  That chip was intended to be a general-purpose
architecture, but the compiler guided decisions on what features were
important.

Four instructions were deleted relatively late in the design process,
and you can see the places where they would have been if you look at
any early 32000 family die.  There are four clear stripes that span
the microcode ROM.  I believe these are visible on all 32000 family
devices through the NS32332.  If I remember correctly, the CPU was
reimplemented in the NS32532, at which point the stripes disappeared.

[Too bad they didn't have time to debug the chip before they shipped
it.  The NS chips, at least the early ones, were so buggy as to be
almost unusable. -John]

[toc] | [prev] | [next] | [standalone]

#2667

On 7/18/11 5:26 PM, Mark Thorson wrote:
> It could be argued that the National Semiconductor NS16032 (later
> renamed NS32016) qualifies.  The designers Les Kohn and Dan O'Dowd
> started with an instruction set more-or-less based on the VAX and
> pared it down to what they considered a minimum.  Dan wrote a Pascal
> compiler that guided the design of the architecture in the sense that
> every time the chip designers in Israel asked whether they could
> delete a feature Les would turn to Dan and ask how that would affect
> the compiler.  That chip was intended to be a general-purpose
> architecture, but the compiler guided decisions on what features were
> important.
>
> Four instructions were deleted relatively late in the design process,
> and you can see the places where they would have been if you look at
> any early 32000 family die.  There are four clear stripes that span
> the microcode ROM.  I believe these are visible on all 32000 family
> devices through the NS32332.  If I remember correctly, the CPU was
> reimplemented in the NS32532, at which point the stripes disappeared.
>
> [Too bad they didn't have time to debug the chip before they shipped
> it.  The NS chips, at least the early ones, were so buggy as to be
> almost unusable. -John]

Yes, I was very interested in the instruction descriptions for the
NS32016.  Seems it had a "CASE" assembly language instruction.
But I heard that the chip had hardware problems that were *never*
worked out...  Too bad.

--
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch

csiph-web