On Mon, 28 Feb 2000, Shawn T. Rutledge wrote: Yes, I had planned to. My SLR has been cranky recently, and I needed some photos from an event I performed at so I picked up one of those single-use jobs and have been filling up the rest of the roll with stuff from my collection. Let's hope they turn out respectably. (: One of the things I wanted to accomplish is to illustrate the amazing amounts of miniaturization 13 years can see. For example, one of the photos will be of one of the 1 MW ECC memory boards next to a pair of 32 MB ECC SIMMs from an HP 715. Anyway. The parens are where they normally are (over 9 and 0), but are also available unshifted where the square brackets would normally be. The square brackets have been moved to where the curly brackets would normally be (on this keyboar, above the unshifted parens) and the curly brackets have been moved to shifted keys which are in Siberia. What I find most amusing is the sheer number of 'modifier' keys on the keyboard. Caps-lock, shift, symbol, hyper, super, meta, control, and mode-lock. Plus perhaps one or two more which work as modifiers but which I don't recognise as such. According to the docs, the keyboard has 'unlimited rollover', meaning if you hit a key, the machine takes note of it no matter how many other keys you're holding down at the time. Mind-boggling. Apparently someone saw a great need for a user to be able to type an n-bit character set directly I'm not sure, but I don't think that X11 existed at the time this machine was current in 1987. X10, maybe, but the windowing system is its own thing. Nothing too fancy. I'd put it on par with the Apollo DM in terms of the kind of functionality it attempts to provide. Still? I'd be surprised. According to the User's Guide to Symbolics Computers: "The power, speed, and flexibility of Symbolics processing machines result Some of the special architecture features include: Tagged architecture Multiple caches Hardware stack management Pipelined instruction cycles Parallel processing Hardware assisted garbage collection Fully ECC'ed system memory (end of quote) I'm very intrigued by what I've learned about the system so far and am anxious to start it up and give it a try. I get the feeling that the LISPM is something of a transputer (like the parallel i860 boards that Microway used to sell which fit in an Intel PC), but with the balance of power between the transputer board and its host (LISPM and FEP, respectively) swapped around so that instead of the PC's OS hosting software which crunches away on the transputer, the OS actually runs on the LISPM, and the FEP's job is to boot the environment and then to handle I/O once the environment is running. I don't feel like I've described it very articulately, but I only vaguely understand what's going on at this point anyway. Still. It's an interesting conceptual leap! ok r.

On Mon, Feb 28, 2000 at 08:40:31PM -0500, r. 'bear' stricklin wrote: Not sure what that is? So I guess maybe that wasn't taken for granted back then huh? Hmmm. Now that'd still be cutting-edge if implemented on a modern processor... Just saw a slashdot article about it that pointed here... http://csl.cs.iit.edu/~dmm/ -- _______ http://www.bigfoot.com/~ecloud (_ | |_) ecloud(a)bigfoot.com finger rutledge(a)cx47646-a.phnx1.az.home.com __) | | \__________________________________________________________________ Join the ProcessTree Network: For-pay Internet distributed processing. http://www.ProcessTree.com/?sponsor=5903

"Sean 'Captain Napalm' Conner" <spc(a)armigeron.com> wrote: Indeed. It was somewhat non-traditional even as tagged architectures went. Rather than tagging every memory location, memory was considered as objects. Each object has a type, which can either be a hardware-interpreted system type (such as Processor, Process, Port, Context, Domain) or a software- defined type. In a given Context (procedure/function invocation), software can only access objects for which that context has an access descriptor (AD). The AD is a capability, which means that it controls the access rights to the object pointed to. For instance, objects have hardware-interpreted read and write rights, as well as other rights that vary depending on the object type. Each object is divided into two parts, the data part and the access part. The access part contains ADs only. The data part can not contain ADs. The instruction set does not even provide any method whereby software could attempt to store an AD into the data part, or data into the access part. This split between ADs and data means that the software can never try to dereference other data as if it were an AD, nor can it corrupt an AD by overwriting it with random data. (There's no inherent protection against writing the "wrong" AD over the "right" one, if you have write rights to the segment.) The architecture is really quite elegant. The big problems with it are: 1) It's slow, due largely to the limits of the 1975-1981 technology used in the implementation. For instance, on the already-large dice, there was not room for instruction or data caches, although there was a small cache for segment information. Also, the data path between the two chips that made up the general data processor was too narrow. 2) The architecture doesn't map well to languages like C. It would be possible to implement a fully standards-compliant C compiler for the 432, but it is likely that the vast majority of existing real-world C code would not run correctly on the system, because most large C programs make architectural assumptions beyond what the C standard requires the platform to guarantee. I've put some information about the iAPX 432 on my web site: http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/ As I think I've stated here before, I'm looking for ANY 432-related materials (documentation, software, chips, boards, systems, etc.). I've started work on a 432 simulator, but I expect it will take a long time to complete, and if I am unable to obtain a complete copy of the 432 cross-development software, I will be unable to verify the correctness of the simulator. So if you have anything, please let me know. Thanks! Eric

On Tue, Feb 29, 2000 at 05:44:47PM -0500, r. 'bear' stricklin wrote: Seems like a good idea. But there would be a limited fixed set of types available then. Hmmm, wouldn't any MMU have to keep track of the virtual-to-physical mapping? Would it normally just do it in main memory if there isn't usually special cache for that? -- _______ http://www.bigfoot.com/~ecloud (_ | |_) ecloud(a)bigfoot.com finger rutledge(a)cx47646-a.phnx1.az.home.com __) | | \__________________________________________________________________ Join the ProcessTree Network: For-pay Internet distributed processing. http://www.ProcessTree.com/?sponsor=5903

Hi, Billiard ball and that context comparisons (like the 2GB 3.5" hd to that 8" SMD is very good! Liked that and reminds me of comparing that 2.5" to a 5.25 FH hd. :-) That 1MW board looked like you could make it to 2MW board by filling all the empty spaces with memory chips. Wizard -who did play pool for fun when I have chance to.