Honneywell multics? from panels. the inline phots in this message folks -smecc

Funny you should mention this! Dave Bridgham and my 'other' project (other than the QSIC) is something called iMucs, which is a Multics-like OS for Intel x86 machines. The reason for the x86 machines is that i) they have decent segmentation support (well, not the very latest model, which dropped it since nobody was using it), and ii) they are common and cheap. The concept is to pretty much redo Multics, in C, on the x86. The x86's segmentation support is adequate, not great. The Multics hardware had all those indirect addressing modes that the compiler will have to simulate, but the machines are now so freakin' fast (see simulated PDP-11's running at 100 times the speed of the fastest real ones - on antique PC's), that shouldn't be a huge problem. We did identify some minor lossage (e.g. I think the maximum real memory you can support is only a couple of GB), but other than that, it's a pretty good match. The x86 even has rings, and the description sounds like it came out of the Multics hardware manual! Although I have to say, I'm not sure rings sare what I would pick for a protection model - I think something like protection domains, with SUID, are better. (So that e.g. a cross-process callable subsystem with 'private' data could have that data marked R/W only to that user ID. In 'pure' Multics, one can move the subsystem/data into a lower ring to give it _some_ protection - but it still has to be marked R/W 'world', albeit only in that lower ring, for other processes to be able to call the subsystem.) It will need specialized compiler support for cross-segment routine calls, pointers, etc, but I have a mostly-written C compiler that I did (CNU CC is large pile, I wouldn't touch it with a barge-pole) that I can re-purpose. And we'll start with XV6 to get a running start. There would be Standard I/O, and hopefully also something of a Unix emulation, so we could take advantage of a lot of existing software. Anyway, we've been focused on the QSIC (and for me, getting my 11's running), but we hope to start on iMucs in the late spring, when Dave heads off to Alaska, and QSIC work goes into a hiatus. Getting the compiler finished is step 1. You refer here, I assume, to the segmentation stuff?

I think the x86 has more or less what one needs (although, as I say, some of the more arcane indirect modes would have to be simulated). Although my memory of the details of the x86 is a bit old, and I've only ever studied the details of how Multics did inter-segment stuff (in Organick, which doesn't quite correspond to Multics as later actually implemented).

Well, Multics had (IIRC) 4 segment registers, one for the code, one for the stack, one for the linkage segment, and I don't remember what the 4th one was used for. (I don't think Multics had 'heap' and 'data' segments as somone might read those terms; a Multics process would have had, in its address space, many segments to which it had R/W access and in which it kept data.)

But the x86 has that many, and more, so it should be workable, and reasonably efficient. You wouldn't want to put them all in the same segment - that's the whole point of the single-level-store architecture! :-) Or perhaps I'm misunderstanding your point, here? It's been a long time since I look at the x86 segment model, but my

buffer Sorry, I don't follow that? Why does the stack growth direction make a difference? It's just a convention, isn't it, which direction is 'push' and which is 'pop'? The classic buffer overrun attack overruns a buffer in the stack; since a