5 ms·

Bob Barton is in a class of early computer people I don't think can be over-praised. However, just to put a caution on the hyperbole, I had been a journeyman pr

Bob Barton is in a class of early computer people I don't think can be over-praised. However, just to put a caution on the hyperbole, I had been a journeyman programmer in the Air Force and then at NCAR -- the latter to work my way through the last two years of college -- and I just "didn't know anything" except how to code a little and design a little. When I got to grad school 50 years ago in 1966, I was immediately confronted by Ivan Sutherland's Sketchpad, the first Simula, many other things in the actual field, and especially in the ARPA community, and ... Bob Barton himself, who Dave Evans had convinced to be on the Utah faculty for a few years (something he was uncomfortable with). In any case, this was like someone going from the 10th century to the 20th century, where as Arthur C Clarke pointed out, "Advanced science resembles magic". I am quite surprised 50 years later to still feel the same way about these people, but my initial impressions have stuck. They seemed and do seem: magical. I've described Bob a little in "The Early History of Smalltalk" that I wrote for the ACM in 1993 http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/. A truly amazing character (and I should try to write a portrait of him at some point). Both the details, and especially the overall design philosophy of the Burroughs machines are worth close study. What was attempted in the B5000 and B5500 was breathtaking, and as is often the case, perhaps too much in a few places (this happened in the later Flex Machine as well, and in the much later Intel 432). At Parc in the 70s we were able to take a second pass at "higher level architectures" (and so did Bob Barton at Burroughs with the B1700) via mixing microcode with fixed functions. The Parc approach was much simpler and less comprehensive (had to work on relatively inexpensive personal computers, and we had a truly wonderful engineering mind in Chuck Thacker who was instrumental in retaining powerful ideas in a parsimonious fashion). But this hybrid turned out extremely well for a wide variety of needs to make "well-fitted-processors" for higher level languages. Part of the need for the hybrid was to tinker with various kinds of storage schemes, formats, garbage collection, swapping, etc., that were not well understood enough to be put directly into hardware (this was one of the two or three slight flaws in the B5000 scheme). I commend the "The Approach ..." (1961) paper listed above as one of the great papers in our field -- and it must be in the top two or three for max content in six pages. I should also note that Bob was a mathematician, thought like a mathematician, and designed like a mathematician -- engineering was more of a hobby for him (and not one that he always paid a lot of attention to). I had some of the same "hangups" -- including being a constant reader of everything -- and these were part of the basis of our relationship.

nickpsecurity 10y ago
"I've described Bob a little in "The Early History of Smalltalk" that I wrote for the ACM in 1993" That was an amazing read. So much connects now. I'm going to have to think on it as it's a lot to take in for one morning. I do spot some things to immediately reference. "They seemed and do seem: magical." Well, when I read the paper I linked, it does look like so much then-unheard-of stuff compressed into one, short document that magic is apt description. It led to B5000. Not just that, though. Your Smalltalk history showed it also helped shape OOP and your work. A Roger Schell interview showed INFOSEC basically started with Anderson: a Burroughs engineer that looked at people, software, and hardware to find systemic, security risk. Their methods are similar to Barton's w/ different perspective. I bet Anderson's thinking traces to it & Burroughs B5000. So, Barton seemingly out of thin air hits all kinds of critical points in concept space of IT, helps put them into a demo (B5000), and its ripple effects help create OOP (indirectly) and INFOSEC (directly). Fair to call it magic as most people were more narrow and incremental with nowhere near as much impact. " I should also note that Bob was a mathematician, thought like a mathematician, and designed like a mathematician" That makes a lot of sense. His work resembles high-assurance a bit in that he worked from clear specs of what it had to do to primitives that could do it to right combination of pieces. It's like he was formulating and solving equations for high-level programming itself. It's why I originally skipped the paper because I wasn't mathematical enough to read some of it. Then, your HN comment said Barton, I had one paper with that name, and now all kinds of light bulbs are turning on. :) Speaking of people doing magic, I landed on Margaret Hamilton's team a year or two ago: https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29 https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist... http://htius.com/Articles/articles.htm http://htius.com/Articles/articles.htm The "Lessons learned from Apollo" paper suggests they were similarly working in a vacuum around same time as Burroughs stuff was coming out. Invented all sorts of engineering and software principles in the process. Are you aware of any others work that went into that or any influence of such work on your side of the fence? As in, was her team's work... especially person-high stack of correct code... as independent and ground-breaking as it appears? Or building on prior work in a way we just haven't seen? Just curious as I've tied INFOSEC, Burroughs, and your work but not sure how her work or legacy fit into the larger picture. Outside safety-critical systems that is. " the later Flex Machine as well" Is the Flex Machine with tagged hardware and Ten15 VM the same as yours or different? Yours mentioned an "aerospace" company. In any case, I wish I had more details on both as they seem like an extension on Burroughs thinking that sort of appeared and then disappeared. I think a HW-accelerated Ten15 could be valuable today. Even if it was an imperative-style RISC + one customized for functional stuff with a clean IPC or functional call mechanisms to integrate anything written for both. https://en.wikipedia.org/wiki/Flex_machine https://en.wikipedia.org/wiki/Flex_machine "via mixing microcode with fixed functions." I keep recommending groups doing RISC-V, etc to use microcode instead of fixed. The reason being old work showed microcoded processors could be repurposed to do many things. The microcode was also used for speed boosts and atomic execution of arbitrary, instruction sequences. Do you second the recommendation of keeping microcode in CPU's wherever possible? " Part of the need for the hybrid was to tinker with various kinds of storage schemes, formats, garbage collection, swapping, etc., that were not well understood enough to be put directly into hardware" Here's the two leading candidates that are the successors of Burroughs and capability-oriented systems: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ SAFE combines tagged architecture, functional programming, and a device for arbitrary, policy expression and enforcement. It's clean-slate with strong properties. CHERI implements a capability architecture that allows fine-grained enforcement and C compatibility. Runs CheriBSD, a FreeBSD port. I see CHERI as an interim solution with SAFE going in direction of more, ideal system. I think they can be mixed. Yet, I think CHERI might not be thorough enough and SAFE is more complex than needed. I thought a subset of SAFE could run an Oberon System port with instant practicality. So, here's what lines I'm thinking along that I'd like to run by you. I started with i432 successor, the i960. The manual has nice reference of its capabilities. Amazing compromise between an i432 and a RISC. https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 What it had was common RISC stuff you can run anything with, MMU, error handling of common errors, and object descriptors for OOP constructions or POLA enforcement. The other thing it had was speed despite all that. So, start with something like that for RISC-V or OpenSPARC. Implement, a la B5000 or SAFE, some specific, tiny-cost checks for basic primitives: pointer/array bounds-checks; stack protection if it has one; code vs data tag (or Itanium-style read/write/execute per word or page); labeling & protection of pointers themselves. These checks run in parallel in tiny HW as CPU runs so essentially no overhead. IOMMU auto-manages tagging of incoming or outgoing I/O data to fit the model. Any failure takes CPU to exception handler with access to relevant data. Optional, dedicated HW for concurrent GC possibly built-in to MMU like some LISP machines. Implemented either clean-slate or with configurable, open CPU like Gaisler's Leon3. It seems those minimal, primitive protections knock out 90+% of the problems. Functional can be mapped to them. Extra error handling or object descriptors, like in i960, do much more while avoiding heavy-weight constructions. I think this is a nice start. I have primitives for safe concurrency, too. What do you think is absolute minimum, safe primitives on top of that we need for OOP like a safe Smalltalk? I don't do dynamic, late binding, or any of that currently. I don't know if it needs special consideration in HW or if prior HW above could handle it with compiler doing all that. Anything come to mind? And thanks for the time and helping me connect dots in IT history. :)

nickpsecurity 10y ago

"I've described Bob a little in "The Early History of Smalltalk" that I wrote for the ACM in 1993" That was an amazing read. So much connects now. I'm going to have to think on it as it's a lot to take in for one morning. I do spot some things to immediately reference. "They seemed and do seem: magical." Well, when I read the paper I linked, it does look like so much then-unheard-of stuff compressed into one, short document that magic is apt description. It led to B5000. Not just that, though. Your Smalltalk history showed it also helped shape OOP and your work. A Roger Schell interview showed INFOSEC basically started with Anderson: a Burroughs engineer that looked at people, software, and hardware to find systemic, security risk. Their methods are similar to Barton's w/ different perspective. I bet Anderson's thinking traces to it & Burroughs B5000. So, Barton seemingly out of thin air hits all kinds of critical points in concept space of IT, helps put them into a demo (B5000), and its ripple effects help create OOP (indirectly) and INFOSEC (directly). Fair to call it magic as most people were more narrow and incremental with nowhere near as much impact. " I should also note that Bob was a mathematician, thought like a mathematician, and designed like a mathematician" That makes a lot of sense. His work resembles high-assurance a bit in that he worked from clear specs of what it had to do to primitives that could do it to right combination of pieces. It's like he was formulating and solving equations for high-level programming itself. It's why I originally skipped the paper because I wasn't mathematical enough to read some of it. Then, your HN comment said Barton, I had one paper with that name, and now all kinds of light bulbs are turning on. :) Speaking of people doing magic, I landed on Margaret Hamilton's team a year or two ago: https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29 https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist... http://htius.com/Articles/articles.htm http://htius.com/Articles/articles.htm The "Lessons learned from Apollo" paper suggests they were similarly working in a vacuum around same time as Burroughs stuff was coming out. Invented all sorts of engineering and software principles in the process. Are you aware of any others work that went into that or any influence of such work on your side of the fence? As in, was her team's work... especially person-high stack of correct code... as independent and ground-breaking as it appears? Or building on prior work in a way we just haven't seen? Just curious as I've tied INFOSEC, Burroughs, and your work but not sure how her work or legacy fit into the larger picture. Outside safety-critical systems that is. " the later Flex Machine as well" Is the Flex Machine with tagged hardware and Ten15 VM the same as yours or different? Yours mentioned an "aerospace" company. In any case, I wish I had more details on both as they seem like an extension on Burroughs thinking that sort of appeared and then disappeared. I think a HW-accelerated Ten15 could be valuable today. Even if it was an imperative-style RISC + one customized for functional stuff with a clean IPC or functional call mechanisms to integrate anything written for both. https://en.wikipedia.org/wiki/Flex_machine https://en.wikipedia.org/wiki/Flex_machine "via mixing microcode with fixed functions." I keep recommending groups doing RISC-V, etc to use microcode instead of fixed. The reason being old work showed microcoded processors could be repurposed to do many things. The microcode was also used for speed boosts and atomic execution of arbitrary, instruction sequences. Do you second the recommendation of keeping microcode in CPU's wherever possible? " Part of the need for the hybrid was to tinker with various kinds of storage schemes, formats, garbage collection, swapping, etc., that were not well understood enough to be put directly into hardware" Here's the two leading candidates that are the successors of Burroughs and capability-oriented systems: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ SAFE combines tagged architecture, functional programming, and a device for arbitrary, policy expression and enforcement. It's clean-slate with strong properties. CHERI implements a capability architecture that allows fine-grained enforcement and C compatibility. Runs CheriBSD, a FreeBSD port. I see CHERI as an interim solution with SAFE going in direction of more, ideal system. I think they can be mixed. Yet, I think CHERI might not be thorough enough and SAFE is more complex than needed. I thought a subset of SAFE could run an Oberon System port with instant practicality. So, here's what lines I'm thinking along that I'd like to run by you. I started with i432 successor, the i960. The manual has nice reference of its capabilities. Amazing compromise between an i432 and a RISC. https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 What it had was common RISC stuff you can run anything with, MMU, error handling of common errors, and object descriptors for OOP constructions or POLA enforcement. The other thing it had was speed despite all that. So, start with something like that for RISC-V or OpenSPARC. Implement, a la B5000 or SAFE, some specific, tiny-cost checks for basic primitives: pointer/array bounds-checks; stack protection if it has one; code vs data tag (or Itanium-style read/write/execute per word or page); labeling & protection of pointers themselves. These checks run in parallel in tiny HW as CPU runs so essentially no overhead. IOMMU auto-manages tagging of incoming or outgoing I/O data to fit the model. Any failure takes CPU to exception handler with access to relevant data. Optional, dedicated HW for concurrent GC possibly built-in to MMU like some LISP machines. Implemented either clean-slate or with configurable, open CPU like Gaisler's Leon3. It seems those minimal, primitive protections knock out 90+% of the problems. Functional can be mapped to them. Extra error handling or object descriptors, like in i960, do much more while avoiding heavy-weight constructions. I think this is a nice start. I have primitives for safe concurrency, too. What do you think is absolute minimum, safe primitives on top of that we need for OOP like a safe Smalltalk? I don't do dynamic, late binding, or any of that currently. I don't know if it needs special consideration in HW or if prior HW above could handle it with compiler doing all that. Anything come to mind? And thanks for the time and helping me connect dots in IT history. :)