In a nutshell, the B5000 embodied a number of great ideas in its architecture.
Design paper by Bob Barton in 1961, machine appeared ca 1962-3.
-- multiple CPUs
-- rotating drum secondary memory
-- automatic process switching
-- no assembly code programming, all was done in ESPOL (executive systems
problem oriented language), an extended version of ALGOL 60.
-- this produced polish postfix code from a "pass and a half" compiler.
-- Tron note: the OS built in ESPOL was called the "MCP" (master control
program).
-- direct execution of polish postfix code
-- code was reentrant
-- code in terms of 12 bit "syllables" (we would call them "bytes") 4 to a 48
bit word
-- automatic stack
-- automatic stack frames for parameters and temporary variables
-- code did not have any kind of addresses
The most unusual part was the treatment of memory and environments
-- every word was marked with a "flag bit" -- which was "outside" of normal
program space -- and determined whether a word was a "value" (a number) or a
"descriptor"
-- code was "granted" an "environment" in the form of (1) a "program reference
table" (essentially an object instance) containing values and descriptors, and
(2) a stack with frame. Code could only reference these via offsets to
registers that themselves were not in code's purview. (This is the basis of the
first capability scheme)
-- the protected descriptors were the only way resources could be accessed and
used.
-- fixed and floating point formats were combined for numbers
-- array descriptors automatically checked for bounds violations, and allowed
automatic swapping (one of the bits in an array descriptor was "presence" and
if "not present" the address was a disk reference, if "present" the address was
a core storage reference, etc.
-- procedure descriptors pointed to code.
-- a code syllable could ask for either a value to be fetched to the top of the
stack ("right hand side" expressions), or a "name" (address) to be fetched
(computing the "left hand side").
-- if the above ran into a procedure descriptor with a "value call" then the
procedure would execute as we would expect. If it was a "name call" then a bit
was set that the procedure could test so one could compute a "left hand side"
for an expression. In other words, one could "simulate data". (The difficulty
of simulating a sparse array efficiently was a clue for me of how to think of
object-oriented simulation of classical computer structures.)
-----------------
As for the Alto in 1973, it had a register bank, plus 16 program counters into
microcode (which could execute 5-6 instructions within each 750ns main memory
cycle). Conditions/signals in the machine were routed through separate logic to
determine which program counter to use for the next microinstruction. There was
no delay between instruction executions i.e. the low level hardware tasking was
"zero-overhead".
(The overall scheme designed by Chuck Thacker was a vast improvement over my
earlier Flex Machine -- which had 4 such program counters, etc.)
The low level tasks replaced almost all the usual hardware on a normal
computer: disk and display and keyboard controllers, general I/O, even refresh
for the DRAM, etc.
This was a great design: about 160 MSI chips plus memory.
Cheers,
Alan
>________________________________
> From: Shawn Morel <shawnmo...@me.com>
>To: Kevin Jones <investtcart...@yahoo.com>; Fundamentals of New Computing
><fonc@vpri.org>
>Cc: Alan Kay <alan.n...@yahoo.com>
>Sent: Sunday, May 27, 2012 6:50 PM
>Subject: Re: [fonc] Question about the Burroughs B5000 series and
>apability-based computing
>
>Kevin,
>
>I'll quote one of my earlier questions to the list - in it I had a few
>pointers that you might find a useful starting place.
>> In the videotaped presentation from HIPK
>> (http://www.bradfuller.com/squeak/Kay-HPIK_2011.mp4) you made reference to
>> the Burroughs 5000-series implementing capabilities.
>
>
>There's also a more detailed set of influences / references to Bob Barton and
>the B* architectures in part 3 of the early history of smalltalk:
>http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html
>
>"I liked the B5000 scheme, but Butler did not want to have to decode bytes,
>and pointed out that since an 8-bit byte had 256 total possibilities, what we
>should do is map different meanings onto different parts of the "instruction
>space." this would give us a "poor man's Huffman code" that would be both
>flexible and simple. All subsequent emulators at PARC used this general
>scheme." [Kay]
>
>You should take the time to read that entire essay, it's chock-full of great
>idea launching points :)
>
>Note that the Alto could simulate (I believe) 16 "instances". Not quite a full
>on bare metal VM the way VMware grossly virtualized an entire x86 system, but
>much more capable than what you'd call a hardware thread (e.g. processor cores
>or hyper threading).
>
>> Could you elaborate on how capabilities were structured, stored and
>> processed in the the B5000 series or point me to appropriate reading
>> material?
>
>I've been able to find some good pointers to the B5000, like this gem:
>http://www.cs.virginia.edu/brochure/images/manuals/b5000/descrip/descrip.html
>
>and of course Barton's "A New approach to the Functional Design of a Digital
>Computer".
>
>Another approach in the same "style" of rich system design would be the
>whirlwind:
>http://www.dtic.mil/cgi-bin/GetTRDoc?AD=AD694615&Location=U2&doc=GetTRDoc.pdf
>
>The part I still can't find info about is the B220 data tape program written
>by the air force officer that had its own bootstrapping code on how to read
>its data format (very Forth-esque).
>
>shawn
>>
>> Best regards,
>>
>> Kevin Jones
>>
>> P.S. - I really enjoy the work going on at VPRI.
>> _______________________________________________
>> fonc mailing list
>> fonc@vpri.org (mailto:fonc@vpri.org)
>> http://vpri.org/mailman/listinfo/fonc
>
>
>
>
>
>_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
