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

Groups > comp.arch > #3623 > unrolled thread

i432 on Bitsavers?

Back to article view | Back to comp.arch

Contents

  i432 on Bitsavers? vandys@vsta.org - 2011-09-11 23:15 +0000
    Re: i432 on Bitsavers? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-11 21:03 -0700
      Re: i432 on Bitsavers? Edward Feustel <efeustel@hughes.net> - 2011-09-12 07:17 -0400
        tagged descriptors Brett Davis <ggtgp@yahoo.com> - 2011-09-12 16:46 -0500
          Re: tagged descriptors Brett Davis <ggtgp@yahoo.com> - 2011-09-14 11:04 -0500
            Re: tagged descriptors Brian Drummond <brian@shapes.demon.co.uk> - 2011-09-14 19:57 +0000
    Re: i432 on Bitsavers? Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-12 07:51 -0400

#3623 — i432 on Bitsavers?

I've always been surprised at how little information remains concerning the
i432 project at Intel.  It was a big project, and certainly came far enough
along that there was a large body of software and documentation.  Did Intel
really deep six it so thoroughly that none of it survived?  It's remarkable
that for such a big project at such a critical juncture in Intel's history,
there are only two documents archived at Bitsavers.

I have at least one book concerning the i432 buried in a box... I should
probably dig it out and scan it in if it's not already archived.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [next] | [standalone]

#3628

On 9/11/2011 4:15 PM, vandys@vsta.org wrote:
> I've always been surprised at how little information remains concerning the
> i432 project at Intel.  It was a big project, and certainly came far enough
> along that there was a large body of software and documentation.  Did Intel
> really deep six it so thoroughly that none of it survived?  It's remarkable
> that for such a big project at such a critical juncture in Intel's history,
> there are only two documents archived at Bitsavers.
>
> I have at least one book concerning the i432 buried in a box... I should
> probably dig it out and scan it in if it's not already archived.
>

I just fouund a copy of the "Intel iAPX 432 Object Primer", Rev 1.1 
(Preliminary), August 1980, author Dick Kaiser.

Marked as having been used by me during my "syncsurvey", the survey of 
existing synchronization primitives I did during my MS at UIUC.  I.e. 
before I worked at Intel.  Although I may have received it at McGill in 
the early 80s.

---


Hmm... how do I contribute to bitsavers.org?   I'm not exactly promising 
to scan it all in, but I may get around to doing so.

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

#3636

On Sun, 11 Sep 2011 21:03:50 -0700, "Andy \"Krazy\" Glew"
<andy@SPAM.comp-arch.net> wrote:

>On 9/11/2011 4:15 PM, vandys@vsta.org wrote:
>> I've always been surprised at how little information remains concerning the
>> i432 project at Intel.  It was a big project, and certainly came far enough
>> along that there was a large body of software and documentation.  Did Intel
>> really deep six it so thoroughly that none of it survived?  It's remarkable
>> that for such a big project at such a critical juncture in Intel's history,
>> there are only two documents archived at Bitsavers.
>>
>> I have at least one book concerning the i432 buried in a box... I should
>> probably dig it out and scan it in if it's not already archived.
>>
>
>I just fouund a copy of the "Intel iAPX 432 Object Primer", Rev 1.1 
>(Preliminary), August 1980, author Dick Kaiser.
>
>Marked as having been used by me during my "syncsurvey", the survey of 
>existing synchronization primitives I did during my MS at UIUC.  I.e. 
>before I worked at Intel.  Although I may have received it at McGill in 
>the early 80s.
>
>---
>
>
>Hmm... how do I contribute to bitsavers.org?   I'm not exactly promising 
>to scan it all in, but I may get around to doing so.

I sent my collection of Intel i432 stuff to the Computer History
Museum. Al may be able to get the material scanned.

One should not forget the book that Elliot I. Organick wrote on it:
A Programmer's View of the Intel 432 System, ISBN 0-070047719-1.

While I was at Prime, we evaluated the 432 including Version 1 and
Version 2.  The interesting difference was in the treatment of
capabilities.

Personally, I prefer the Intel 960XB, a tagged/descriptor oriented
machine.

Regards,
Ed Feustel

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

#3646 — tagged descriptors

In article <80qr675tqlmnhan4dqbi1cjpsjjvd5jj0h@4ax.com>,
 Edward Feustel <efeustel@hughes.net> wrote:

> Personally, I prefer the Intel 960XB, a tagged/descriptor oriented
> machine.

Feel free to expound on the 960XB tagged/descriptors, and what
you really would have wanted.

How this would apply to a pthread (if possible) would be great also.

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

#3664 — Re: tagged descriptors

In article <ggtgp-FC7812.16463112092011@netnews.mchsi.com>,
 Brett Davis <ggtgp@yahoo.com> wrote:

> In article <80qr675tqlmnhan4dqbi1cjpsjjvd5jj0h@4ax.com>,
>  Edward Feustel <efeustel@hughes.net> wrote:
> 
> > Personally, I prefer the Intel 960XB, a tagged/descriptor oriented
> > machine.
> 
> Feel free to expound on the 960XB tagged/descriptors, and what
> you really would have wanted.
> 
> How this would apply to a pthread (if possible) would be great also.

Looking at the instruction manual there is a bunch of stuff you
normally would see in language manual not CPU manual:

Chapter 8, Object Addressing, 8.2.4 Tagging.
Chapter 9, Type Management and Access Control.

Instructions:
CREAD (Create Access Descriptor) on page 18-52.
AMPLIFY (Amplify Rights) page 18-11.
RESTRICT (Restrict Rights) page 18-111.

Overall this does not look horrible, actually seems reasonably
efficient, only the MMU is really slightly different than normal.
(Object IDs instead of flat addresses, but I suspect the object IDs
are actually flat, so the net effect is almost identical.)
Looks like you can run UNIX on this CPU, at good speeds.

Not a lot of people used this chip, would be nice for the comp.arch
community if someone that did use it would speak up on the tradeoffs
and flaws, and if any of the flaws are fundamental instead of temporary.

Is handing out a flat tagged descriptor any different than handing
out a flat memory address?

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

#3670 — Re: tagged descriptors

On Wed, 14 Sep 2011 11:04:13 -0500, Brett Davis wrote:

> Instructions:
> CREAD (Create Access Descriptor) on page 18-52. AMPLIFY (Amplify Rights)
> page 18-11.
> RESTRICT (Restrict Rights) page 18-111.
> 
> Overall this does not look horrible, actually seems reasonably
> efficient, only the MMU is really slightly different than normal.
> (Object IDs instead of flat addresses, but I suspect the object IDs are
> actually flat, so the net effect is almost identical.) Looks like you
> can run UNIX on this CPU, at good speeds.
> 
> Not a lot of people used this chip, would be nice for the comp.arch
> community if someone that did use it would speak up on the tradeoffs and
> flaws, and if any of the flaws are fundamental instead of temporary.

Looking at the 432 documentation I had, from the perspective of the Linn 
Rekursiv at the other end of the 1980s, the 432 was crippled by its 
packaging. It was partitioned into multiple chips (so was the Rekursiv) 
in something like 64-pin packages. and microcode was squeezed like 
toothpaste down a 16-bit bus.

With 299-pin PGAs the Rekursiv could afford a 128 bit microcode word, so 
a lot of things that took multiple cycles on the 432 were a single cycle 
on the Rekursiv in parallel with several other operations.

I wouldn't want to push the parallels between the two processors very 
far, and my experience was with the Rekursiv not the 432, but my 
perception is that a lot of the 432's problems were temporary 
technological limitations rather than fundamental. Others (like n-bit 
instruction alignment where n could be 6 or other weird numbers) were 
probably self-inflicted and unnecessary...

- Brian

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

#3637

vandys@vsta.org writes:
> I have at least one book concerning the i432 buried in a box... I should
> probably dig it out and scan it in if it's not already archived.

similar/recent 432 thread/posts in a.f.c.
http://www.garlic.com/~lynn/2011l.html#2 68000 assembly language programming
http://www.garlic.com/~lynn/2011l.html#15 Selectric Typewriter--50th Anniversary

references even older a.f.c. post
http://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software that didn't

mentions having three i432 books in boxes ... and reproduced on of the
intros ... which referenced s/38

somewhat concurrent with i432, TYMSHARE did capability-based operating
system "gnosis" for ibm mainframe. When M/D bought TYMSHARE in the
mid-80s, gnosis was spun off as keykos (disclaimer: I was brought in to
do gnosis audit as part of the spinoff). 
http://www.cis.upenn.edu/~KeyKOS/

Some more recent capability-based claim to trace back to gnosis;
http://en.wikipedia.org/wiki/CapROS

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web