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


Groups > comp.arch > #2513 > unrolled thread

Architecture / Instruction Set / Language co-design.

Started byRoberto Waltman <usenet@rwaltman.com>
First post2011-07-14 15:37 -0400
Last post2011-07-20 01:10 -0500
Articles 20 on this page of 35 — 21 participants

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 1 of 2  [1] 2  Next page →


#2513 — Architecture / Instruction Set / Language co-design.

FromRoberto Waltman <usenet@rwaltman.com>
Date2011-07-14 15:37 -0400
SubjectArchitecture / Instruction Set / Language co-design.
Message-ID<vbhu17tqe8f03a9i8tar3kpoirg02l8iuj@4ax.com>
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 ]

[toc] | [next] | [standalone]


#2514

Fromblp@cs.stanford.edu (Ben Pfaff)
Date2011-07-14 13:03 -0700
Message-ID<87zkkgljeb.fsf@blp.benpfaff.org>
In reply to#2513
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.

Sun's JavaStation?  Wikipedia does indicate that the chip to run
Java bytecode natively "doesn't appear to have been produced",
however.
-- 
"J'avais trouv'e ma religion :
 rien ne me parut plus important qu'un livre.
 La biblioth`eque, j'y voyais un temple."
--Jean-Paul Sartre

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


#2524

FromPeter Flass <Peter_Flass@Yahoo.com>
Date2011-07-14 21:16 -0400
Message-ID<ivo4dl$jf4$1@dont-email.me>
In reply to#2514
On 7/14/2011 4:03 PM, Ben Pfaff wrote:
> 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.
>
> Sun's JavaStation?  Wikipedia does indicate that the chip to run
> Java bytecode natively "doesn't appear to have been produced",
> however.


Here's a very early reference:

"A general-purpose high-level language machine for minicomputers"
Bradford W. Wade and Victor B. Schneider
Published in:
Proceedings of the meeting on SIGPLAN/SIGMICRO interface archive
ACM New York, NY, USA ©1973
http://dx.doi.org/10.1145/872756.807039

<quote>
In the course of our investigations into the design of translator 
writing systems (compiler-compilers), it has been established [2] that a 
certain set of “semantic primitives” can adequately express the major 
portion of the semantics of programs written in any of the several 
common high-level languages (e.g., PL/I, ALGOL W). It was also observed 
that each of these semantic primitives, while representing 
frequently-used high-level language constructs, corresponds to 
predictable sequences of machine-language instructions in the object 
code of programs. Similarly, other authors have noted that conventional 
computer instruction sets are less than satisfactory as target languages 
for high-level language programs and have offered, as a solution to this 
problem, hardware or firmware processors designed specifically for 
programs written in a particular high-level language—the machine 
language and the programming language are essentially identical. The 
best known early example of such a processor is Helmut Weber's 
microprogrammed implementation of the EULER language on an IBM 360/30. 
[5] More recently, Burroughs Corporation has produced the B1700, a 
computer that has a microprogrammed language processor for each of 
several languages, the appropriate one of which is loaded into control 
memory to interpret a given program. [6,7] Such processors show 
significant speed increases over conventional computers of comparable 
basic speed in executing programs written in their particular language, 
but are too specialized to execute other languages efficiently. 
Therefore we have conjectured that, by designing a computer organization 
which implements a set of semantic primitives similar to Lancaster's via 
microprogramming, one instruction per primitive (so that the work 
required by a DO statement, for example, is performed in the firmware 
rather than in the software), we can achieve speed increases approaching 
those of the single-language processors, while retaining the flexibility 
characteristic of conventional computer organizations. This paper 
describes those primitives which we have chosen for initial 
implementation, and presents some preliminary results on the speedups 
obtained.
</quote>

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


#2515

FromPeter Flass <Peter_Flass@Yahoo.com>
Date2011-07-14 16:06 -0400
Message-ID<ivni5d$2vj$2@dont-email.me>
In reply to#2513
On 7/14/2011 3:37 PM, 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?
>

IBM 5100: APL.

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


#2526

FromCharles Richmond <frizzle@tx.rr.com>
Date2011-07-14 20:42 -0500
Message-ID<ivo5tr$l3o$5@dont-email.me>
In reply to#2515
On 7/14/11 3:06 PM, Peter Flass wrote:
> On 7/14/2011 3:37 PM, 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?
>>
>
> IBM 5100: APL.

ISTM that I read the IBM 5100 APL was just the IBM 1130 APL run 
with an emulator on the box...  That would seem to slow things 
down a bunch.

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

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


#2532

FromPeter Flass <Peter_Flass@Yahoo.com>
Date2011-07-15 07:50 -0400
Message-ID<ivp9id$5tr$1@dont-email.me>
In reply to#2526
On 7/14/2011 9:42 PM, Charles Richmond wrote:
> On 7/14/11 3:06 PM, Peter Flass wrote:
>> On 7/14/2011 3:37 PM, 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?
>>>
>>
>> IBM 5100: APL.
>
> ISTM that I read the IBM 5100 APL was just the IBM 1130 APL run with an
> emulator on the box... That would seem to slow things down a bunch.
>

 From what I gather the machine (SCAMP originally) was heavily 
microcoded, I believe the original acronym is something like "Small 
Computer with APL Microcode <something>".  I don't know too much about it.

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


#2535

FromAnne & Lynn Wheeler <lynn@garlic.com>
Date2011-07-15 09:56 -0400
Message-ID<m3d3hbhclg.fsf@garlic.com>
In reply to#2532
Peter Flass <Peter_Flass@Yahoo.com> writes:
> From what I gather the machine (SCAMP originally) was heavily
> microcoded, I believe the original acronym is something like "Small
> Computer with APL Microcode <something>".  I don't know too much about
> it.

recent scamp reference from last month
http://www.garlic.com/~lynn/2011h.html#53 Happy 100th Birthday, IBM!

5100, SCAMP: Special Computer, APL Machine Portable
http://en.wikipedia.org/wiki/IBM_5100

based on the PALM processor: Put All Logic in Microcode
http://en.wikipedia.org/wiki/IBM_PALM_processor

cambridge science center had taken apl\360, and stripped out most of the
monitor stuff (multitasking, swamping, etc) for cms\apl (under cp67,
also redo storage management for large demand paged virtual memory
environment; typical apl\360 had been 16kbyte to 32kbyte real-memory,
swapped workspaces). recent news item mentioning cp67

Before the PC: IBM invents virtualisation (Cambridge skunkworks)
http://www.theregister.co.uk/2011/07/14/brief_history_of_virtualisation_part_2/page2.html
in this post:
http://www.garlic.com/~lynn/2011i.html#54

misc. past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

5100 was done at palo alto science center. About the same time, Palo
Alto also does apl\cms (for vm370) and apl microcode for 370/145.

one of the largest APL services was HONE (first cp67 then moved to
VM370) ... internal world-wide sales & marketing support:
http://www.garlic.com/~lynn/subtopic.html#hone

in the mid-70s, the US HONE datacenters were consolidated in building
across the back parking lot from Palo Alto Science center. other trivia,
looking at web satellite phote of the area ... a newer building was
built next to HONE datacenter (which has a different occupant now)
... that newer bldg is now occupied by FACEBOOK.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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


#2542

FromJohn Levine <johnl@iecc.com>
Date2011-07-15 17:38 +0000
Message-ID<ivptv2$om5$1@gal.iecc.com>
In reply to#2532
>>> IBM 5100: APL.  ...
> From what I gather the machine (SCAMP originally) was heavily 
>microcoded, I believe the original acronym is something like "Small 
>Computer with APL Microcode <something>".  I don't know too much about it.

No, it was called PALM, and was a fairly ordinary micro.  It ran one
interpreter for Basic, and a 360 subset for APL.  But it wasn't
originally designed for a particular language.

I don't know whether the APL on a 360 was an engineering decision that
it was easier to debug a 360 emulator than an APL interpreter, or it
was an experiment that escaped from the lab.

R's,
John

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


#2544

FromCharles Richmond <frizzle@tx.rr.com>
Date2011-07-15 23:22 -0500
Message-ID<ivr3m6$2qr$5@dont-email.me>
In reply to#2542
On 7/15/11 12:38 PM, John Levine wrote:
>>>> IBM 5100: APL.  ...
>>  From what I gather the machine (SCAMP originally) was heavily
>> microcoded, I believe the original acronym is something like "Small
>> Computer with APL Microcode<something>".  I don't know too much about it.
>
> No, it was called PALM, and was a fairly ordinary micro.  It ran one
> interpreter for Basic, and a 360 subset for APL.  But it wasn't
> originally designed for a particular language.
>
> I don't know whether the APL on a 360 was an engineering decision that
> it was easier to debug a 360 emulator than an APL interpreter, or it
> was an experiment that escaped from the lab.
>

 From the web page:

<http://www.brouhaha.com/~eric/retrocomputing/ibm/5100/>

"Predecessor:

The 5100 was based on the design of an earlier proof-of-concept 
system called SCAMP, for "Special Computer, APL Machine Portable". 
SCAMP was also based on the PALM processor, but used a Norelco 
(Philips) compact cassette drive instead of the 3M cartridge. 
SCAMP emulated an IBM 1130 minicomputer in order to run APL\1130. 
SCAMP is in the Smithsonian Institution."


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

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


#2564

FromJohn Levine <johnl@iecc.com>
Date2011-07-17 19:33 +0000
Message-ID<ivvded$22cu$1@gal.iecc.com>
In reply to#2544
>> No, it was called PALM, and was a fairly ordinary micro.  It ran one
>> interpreter for Basic, and a 360 subset for APL.  But it wasn't
>> originally designed for a particular language.
>>
>> I don't know whether the APL on a 360 was an engineering decision that
>> it was easier to debug a 360 emulator than an APL interpreter, or it
>> was an experiment that escaped from the lab.

>"Predecessor:

Right, not the 5100.

>SCAMP emulated an IBM 1130 minicomputer in order to run APL\1130. 

Having used APL\1130 (did anyone else?) I can assure you that even by
the quaint standards of the day, it was not a product that was worth
paying for, much less buying an entire computer to run.

APL\360, on the other hand, worked great.

R's,
John

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


#2516

Fromcb@mer.df.lth.se (Christian Brunschen)
Date2011-07-14 20:25 +0000
Message-ID<ivnjbt$bk1$1@dont-email.me>
In reply to#2513
In article <vbhu17tqe8f03a9i8tar3kpoirg02l8iuj@4ax.com>,
Roberto Waltman  <me@privacy.net> 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?

The Linn Rekursiv seems interesting at least in the context:

  http://en.wikipedia.org/wiki/Rekursiv
  http://www.brouhaha.com/~eric/retrocomputing/rekursiv/

>--
>Roberto Waltman

// Christian

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


#2517

FromEricP <ThatWouldBeTelling@thevillage.com>
Date2011-07-14 17:42 -0400
Message-ID<3qJTp.58371$SG4.45010@newsfe03.iad>
In reply to#2513
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 ]

The Intel iAPX 432 was marketed as a processor for Ada

http://en.wikipedia.org/wiki/Intel_iAPX_432

Eric

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


#2556

Frommac <acolvin@efunct.com>
Date2011-07-17 15:31 +0000
Message-ID<516386065332608708.623253acolvin-efunct.com@news.eternal-september.org>
In reply to#2517
> 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.

The 432 had hardware object protection of the kind that might be useful for
machine language and C,  but should have been unnecessary for Ada's strong
typing.

It's true that the 432 had support for garbage collection, bug it wasn't
clear that Ada requirdd this.

The 432 also promoted the idea of "the Silicon Operating System". Since
OS's are expensive and unreliable, we'd be better off if they were
implemented in hardware. I heard that elements of the design wound up in
the 286 et seq.

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


#2558

FromBill Findlay <yaldnif.w@blueyonder.co.uk>
Date2011-07-17 16:59 +0100
Message-ID<CA48C56F.E647%yaldnif.w@blueyonder.co.uk>
In reply to#2556
On 17/07/2011 16:31, in article
516386065332608708.623253acolvin-efunct.com@news.eternal-september.org,
"mac" <acolvin@efunct.com> 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.

It was entirely bogus, in my view.

> The 432 had hardware object protection of the kind that might be useful for
> machine language and C,  but should have been unnecessary for Ada's strong
> typing.

And for precisely that reason.

> It's true that the 432 had support for garbage collection, bug it wasn't
> clear that Ada requirdd this.

It does not, and never has done.

> The 432 also promoted the idea of "the Silicon Operating System". Since
> OS's are expensive and unreliable, we'd be better off if they were
> implemented in hardware. I heard that elements of the design wound up in
> the 286 et seq.

There is some value in providing a very small core of security-sensitive
functions in hardware, as GEC did with Nucleus in their 4080 machine.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

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


#2559

FromAnne & Lynn Wheeler <lynn@garlic.com>
Date2011-07-17 12:11 -0400
Message-ID<m362n0q440.fsf@garlic.com>
In reply to#2556
mac <acolvin@efunct.com> writes:
> 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.
>
> The 432 had hardware object protection of the kind that might be useful for
> machine language and C,  but should have been unnecessary for Ada's strong
> typing.
>
> It's true that the 432 had support for garbage collection, bug it wasn't
> clear that Ada requirdd this.
>
> The 432 also promoted the idea of "the Silicon Operating System". Since
> OS's are expensive and unreliable, we'd be better off if they were
> implemented in hardware. I heard that elements of the design wound up in
> the 286 et seq.


432 had some similarities to mainframe (failed) Future System effort in
the early 70s ... but mostly microcode rather than silicon. past posts
mentioning FS
http://www.garlic.com/~lynn/submain.html#futuresys

432 group gave presentation at acm sigops (asilomar, 79? or 81?). one of the
big problems was that there was large amount of complex code directly in
silicon ... which had tendency to have bugs ... and it was very
expensive to correct.

i still have some old 432 reference manuals

misc. past posts mentioning 432
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000d.html#57 iAPX-432 (was: 36 to 32 bit transition
http://www.garlic.com/~lynn/2000d.html#62 iAPX-432 (was: 36 to 32 bit transition
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software that didn't
http://www.garlic.com/~lynn/2001.html#54 FBA History Question (was: RE: What's the meaning of track overfl ow?)
http://www.garlic.com/~lynn/2001g.html#36 What was object oriented in iAPX432?
http://www.garlic.com/~lynn/2001k.html#2 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002d.html#27 iAPX432 today?
http://www.garlic.com/~lynn/2002d.html#46 IBM Mainframe at home
http://www.garlic.com/~lynn/2002l.html#19 Computer Architectures
http://www.garlic.com/~lynn/2002o.html#5 Anyone here ever use the iAPX432 ?
http://www.garlic.com/~lynn/2002q.html#11 computers and alcohol
http://www.garlic.com/~lynn/2003.html#5 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003e.html#54 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#55 Reviving Multics
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003m.html#23 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#47 Intel 860 and 960, was iAPX 432
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004e.html#52 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#60 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#64 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2004q.html#73 Athlon cache question
http://www.garlic.com/~lynn/2005d.html#64 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005k.html#46 Performance and Capacity Planning
http://www.garlic.com/~lynn/2005o.html#35 Implementing schedulers in processor????
http://www.garlic.com/~lynn/2005q.html#31 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006c.html#47 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?
http://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
http://www.garlic.com/~lynn/2006p.html#15 "25th Anniversary of the Personal Computer"
http://www.garlic.com/~lynn/2006t.html#7 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2007d.html#61 ISA Support for Multithreading
http://www.garlic.com/~lynn/2007r.html#32 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007s.html#36 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job
http://www.garlic.com/~lynn/2008d.html#54 Throwaway cores
http://www.garlic.com/~lynn/2008e.html#32 CPU time differences for the same job
http://www.garlic.com/~lynn/2008h.html#35 Two views of Microkernels (Re: Kernels
http://www.garlic.com/~lynn/2008k.html#22 CLIs and GUIs
http://www.garlic.com/~lynn/2009d.html#52 Lack of bit field instructions in x86 instruction set because of  patents ?
http://www.garlic.com/~lynn/2009i.html#32 Why are z/OS people reluctant to use z/OS UNIX?
http://www.garlic.com/~lynn/2009o.html#13 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009o.html#18 Microprocessors with Definable MIcrocode
http://www.garlic.com/~lynn/2009o.html#46 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture
http://www.garlic.com/~lynn/2010g.html#1 IA64
http://www.garlic.com/~lynn/2010g.html#45 IA64
http://www.garlic.com/~lynn/2010h.html#8 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010h.html#40 Faster image rotation
http://www.garlic.com/~lynn/2010j.html#22 Personal use z/OS machines was Re: Multiprise 3k for personal Use?
http://www.garlic.com/~lynn/2011.html#28 Personal histories and IBM computing
http://www.garlic.com/~lynn/2011c.html#7 RISCversus  CISC
http://www.garlic.com/~lynn/2011c.html#91 If IBM Hadn't Bet the Company

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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


#2587

FromMike Hore <mike_horeREM@OVE.invalid.aapt.net.au>
Date2011-07-19 12:04 +1000
Message-ID<j02onr$sel$1@dont-email.me>
In reply to#2559
On 18/07/11 2:11 AM, Anne & Lynn Wheeler wrote:
>
> i still have some old 432 reference manuals

Would you be able to send these to Al Kossow for scanning and putting on 
Bitsavers?  They'd be valuable to have available for the rest of us.

-- Mike.

---------------------------------------------------------------
      Mike Hore     mike_horeREM@OVE.invalid.aapt.net.au
---------------------------------------------------------------

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


#2561

FromEricP <ThatWouldBeTelling@thevillage.com>
Date2011-07-17 13:02 -0400
Message-ID<uBEUp.2630$%f4.1089@newsfe16.iad>
In reply to#2556
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.

Yes, that is why a phrased it that way.
The LISP machine had to run an OS in addition to LISP
which means it has to do everything other cpus do.

I think a better question would have been
What specific architecture or instruction features on
which machines benefit specific languages or OS requirements?

E.g.
Alpha LDQ_U Load Quadword Unaligned instruction masked the lower
3 address bits allowing them to be used for tagged pointers.

VAX interrupt controller had 4 levels software interrupts
prioritized below the external device priorities for use by the OS.
(only one level of software interrupt should really be needed by
an OS, so as with most things on the VAX, it had 4).

Eric

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


#2563

FromTerje Mathisen <"terje.mathisen at tmsw.no">
Date2011-07-17 20:42 +0200
Message-ID<82nbf8-me72.ln1@ntp6.tmsw.no>
In reply to#2561
EricP wrote:
> I think a better question would have been
> What specific architecture or instruction features on
> which machines benefit specific languages or OS requirements?
>
> E.g.
> Alpha LDQ_U Load Quadword Unaligned instruction masked the lower
> 3 address bits allowing them to be used for tagged pointers.

Wasn't that one of the required instructions to make it possible to 
handle string (byte) operations with 64-bit operations?

I.e. you would use LDQ_U on the (presumably arbitrarily aligned) char * 
passed in to strcpy() etc, along with another operation which would mask 
a register based on the lower three bits.

The key is of course that with such an instruction for the first word, 
all accesses would be aligned, making it safe to load 8 bytes, even if 7 
of them happened to be outside the end of the string. (It works because 
the using of protection is the memory page, which is also aligned.)

The fact that it would also work for languages that like to have tagged 
pointers might have been more of a happy coincidence?

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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


#2574

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2011-07-18 11:49 +0000
Message-ID<2011Jul18.134908@mips.complang.tuwien.ac.at>
In reply to#2563
Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
>EricP wrote:
>> E.g.
>> Alpha LDQ_U Load Quadword Unaligned instruction masked the lower
>> 3 address bits allowing them to be used for tagged pointers.
>
>Wasn't that one of the required instructions to make it possible to 
>handle string (byte) operations with 64-bit operations?

Yes, bytes, 16-bit words, and unaligned accesses to anything are
synthesized with LDQ_U (or you rely on having the BWX instructions,
which allow you to do byte and 16-bit accesses in one instruction).

>I.e. you would use LDQ_U on the (presumably arbitrarily aligned) char * 
>passed in to strcpy() etc, along with another operation which would mask 
>a register based on the lower three bits.

Here's what gcc produces for a byte read:

        lda $16,1($16)
        ldq_u $0,-1($16)
        extqh $0,$16,$0
        sra $0,56,$0

>The fact that it would also work for languages that like to have tagged 
>pointers might have been more of a happy coincidence?

Yes, if it is helpful for them at all.  In most cases the code that
accesses through a tagged pointer knows what the tag is, so you can
use a normal (aligned) load or store and use an offset to turn the
tagged pointer into an aligned access.  E.g., if your lists have tag
3, then you access the head with "ldq ...,-3(...)"  and the tail with
"ldq ..., 5(...)".  The alignment check may be useful as a type check,
or there might be an explicit typecheck before the ldq.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

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


#2566

FromAndrew Reilly <areilly---@bigpond.net.au>
Date2011-07-17 23:14 +0000
Message-ID<98h8mfFhltU1@mid.individual.net>
In reply to#2561
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,

-- 
Andrew

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


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch


csiph-web