TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by Dave Horsfall

A nerdy group on an Aussie list are discussing old Unix cracks, and the infamous "SPL 0" brick-that-box came up. I first saw it in ";login:" (I think), and, err, tried it (as did others)... Can anyone reproduce the code? It went something like: > [ SPL 0 ] > > I only did that once (and you should've heard what he said to me)... > I'm still trying to find the source for it (it was published in a > ";login:" journal) to see if SIMH is vulnerable. The concept was simple enough - fill your entire memory space with an uninterruptible instruction. It would have gone something like: opc = 000230 ; 000230 is the opcode for SPL 0 sys brk, -1 ; or whatever value got you all 64k of address space mov #place, sp jmp place . = opc - 2 ; the -2 is to allow for the PC increment on an instruction fetch, which I believe happens before any execution place: jsr pc, -(pc) Ring any bells, anyone? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] Happy birthday, Internet!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > The Internet ... was born on this day in 1969, when RFC-1 got published I have this vague memory that the Internet-History list decided that the appropriate day was actually the day the format of the v4 headers was set, i.e. 16 June, 1978. (See IEN-68, pg. 12, top.) Picking the date of RFC-1 seems a little odd. Why not the day the first packet was send over a deployed IMP, or the day the RFP was sent out, or the contract let? And the ARPANet was just one predecessor; one might equally have picked a CYCLADES date... > (spelled with a capital "I", please, as it is a proper noun) ... As I > said at a club lecture once, there are many internets, but only one > Internet. I myself prefer the formulation 'there are many white houses, but only one White House'! :-) Noel

7 years, 4 months

Happy birthday, J. Presper Eckert!

by Dave Horsfall

J. Presper Eckert was born on this day in 1919; along with John Mauchly, he was a co-designer of ENIAC, one of the world's first programmable electronic computers. Yes, there is a long-running dispute over whether ENIAC or Colossus was first; being a Pommie, I'm siding with Colossus :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] long lived programs

by Norman Wilson

Steve Johnson: But in this case, part of the requirement was to pass some standard simulation tests (in FORTRAN, of course). He was complaining that these programs had bugs and didn't give the right answer. ==== This reminds me of an episode during my time at Bell Labs. The System V folks wanted to make pipes that were streams; our experience in Research showed that that was useful. We'd done it just by making pipe(2) create a stream. This caused some subtle differences in semantics (pipes became full-duplex; writing to a pipe put a delimiter in the stream, so that a corresponding read on the other end would stop at the delimiter; write(pipefd, "", 0) therefore generated something that would make read(pipeotherfd, buf, len) return 0). We'd been running all our systems that way for a while, and had uncovered no serious problems. But the System V folks were very nervous about it anyway, and wrote a planning document in which they proposed to create a new, different system call to make stream pipes. pipe(2) would make an old-fashioned pipe; spipe(2) (or whatever it was called, I forget the name) had to be called to get a stream. The document didn't really explain the justification for this. To us in Research it just sounded crazy. Someone else was going to attend a meeting with the developers, but at the last minute he had a conflict, so he drafted me to go. Although I can be pretty blunt in writing, I try not to be so much so in person when dealing with people I don't know; so rather than asking how they could be so crazy as to add a new kind of pipe, I asked why they really thought it necessary. It took a little probing, but the answer turned out to be that their management insisted that everything pass an official verification suite to prove compliance with the System V, Consider It Standard; and said verification suite didn't just check that the first file descriptor returned by pipe(2) could be read and the second written, it insisted that the first could not be written and the second not read. Full-duplex pipes didn't meet the standard, it was claimed. I asked what exactly is the standard? The SVID, I was told. What does the SVID really say, I wondered? We got a copy and looked up pipe(2). According to the official standard, the first file descriptor must be readable and the second writeable, but there was no statement that it couldn't work the other way too. Full-duplex pipes did in fact meet the standard; it was the verification suite that, in an excess of zeal, didn't conform. The developers were absolutely delighted with this. They too thought it was stupid to have two different kinds of pipes, particularly given our experience that full-duplex delimited pipes didn't break anything. They were very happy to have Research not just yell at them for doing things differently from us, but help them figure out how to justify doing things right. I don't know just how they took this further with management, but as it came out in SVr4, pipe(2) returned a full-duplex stream. This is still true even unto Solaris 10, where I just tested it. I made friends that day. That developer group kept in touch with me as they did further work on pipes, the terminal driver, pseudo-ttys, and other things. I didn't agree with everything they did, but we were able to discuss it all cordially. Sometimes the verification program just needs to be fixed. And sometimes the developers that seem set on doing the wrong thing really want help in subverting whatever is forcing that on them, because they really do know what the right thing is. Norman Wilson Toronto ON

7 years, 4 months

Re: [TUHS] Happy birthday, Internet!

by Rudi Blom

Just had a look at RFC-1, my first look ever. First thing I noticed is the enormous amount of abbreviations one is assumed to be able to instantly place :-) So looking up IMP for instance the wiki page gives me this funny titbit "When Massachusetts Senator Edward Kennedy learned of BBN's accomplishment in signing this million-dollar agreement, he sent a telegram congratulating the company for being contracted to build the "Interfaith Message Processor"." https://en.wikipedia.org/wiki/Interface_Message_Processor

7 years, 4 months

Re: [TUHS] long lived programs

by Doug McIlroy

> Shortly after I arrived, the comp center announced a brand-new feature -- permanent disc storage! (actually, I think it was a drum...) Irrelevant to the story (or Unix), but it was indeed a disc drive--much more storage per unit volume than drums, which date to the 1940s, if not before. Exact opposite of current technology: super heavy and rigid combs banged in and out of the disk stack. The washing-machine sized machine could be driven to walk across the floor. It would not be nice to be caught in its path. (Fortunately ordinary work loads did not have such an effect.) Vic Vyssotsky calculated that with only 10 times its 10MB capacity, we could have kept the entire printed output since the advent of computers at the Labs on line. Doug

7 years, 4 months

Happy birthday, Internet!

by Dave Horsfall

The Internet (spelled with a capital "I", please, as it is a proper noun) was born on this day in 1969, when RFC-1 got published; it described the IMP and ARPAnet. As I said at a club lecture once, there are many internets, but only one Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

Re: [TUHS] shared objects in Unix (Clem cole) / Accent influence

by Paul Ruizendaal

> Date: Fri, 30 Mar 2018 00:28:13 -0400 > From: Clem cole <clemc(a)ccc.com> > > Also, joy / BSD 4.2 was heavily influenced by Accent (and RIG )and the Mach memory system would eventually go back into BSD (4.3 IIRC) - which we have talked about before wrt to sockets and Accent/Mach’s port concept. From an "outsider looking in” perspective I’m not sure I recognise such heavy influence in the sockets code base. Of course, suitability for distributed systems was an important part of the 4.2BSD design brief and Rick Rashid was one of the steering committee members, that is all agreed. However in the code evolution for sockets I only see two influences that seem not direct continuations from earlier arpanet unices and have a possible Accent origins: - Addition of sendto()/recvfrom() to the API. Earlier code had poor support for UDP and was forced through the TCP focused API’s, with fixed endpoint addresses. It could be Accent inspired, it could also be a natural solution for sending datagrams. For example, Jack Haverty had hacked a “raw datagram” facility into UoI Arpanet Unix around ’79 (it’s in the Unix Tree). - Addition of a facility to pass file descriptors using sendmsg()/recvmsg() in the local domain. This facility was only added at the very last moment (it was not in 4.1c, only in 4.2). I’m being told that the CSRG team procrastinated on this because they did not see much use for it — and indeed it was mostly ignored in the field for the next two decades. Joy had left by that time, so perhaps the dynamics had changed. Earlier I though that the select() call may have come from Accent, but it was inspired by the Ada select statement. Conceptually, it was preceded on Unix by Haverty’s await() call (also ’79). For clarity: I wasn’t there, just commenting on what I see in the code. Paul

7 years, 4 months

dead bstj unix link on wikipedia

by ron minnich

anyone got a fix? https://en.wikipedia.org/wiki/Bell_System_Technical_Journal see this text 1. Ritchie, D.M.; K. Thompson (July–August 1978). "The UNIX Time-Sharing System" <http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>. *Bell System Technical Journal*. *57* (6). Retrieved 2010-10-22

7 years, 4 months

shared objects in Unix

by Paul Winalski

The recent discussion of long-lived applications, and backwards compatibility in Unix, got me thinking about the history of shared objects. My own experience with Linux and MacOS is that statically-linked applications tend to continue working from release to release, but shared objects provided by the OS tend not to be backwards compatible, and one often has to carry around with your application the exact C runtime and other shared objects your program was linked against. This is in big contrast to shared libraries on VMS, where great care is taken to maintain strict backward compatibility release to release. What is the history of shared objects on Unix? When did they first appear, and with what object/executable file format? The a.out ZMAGIC format doesn't seem to support them. I don't recall if COFF does. MACH-O, at least the MacOS dialect of it, supports dynamic libraries. ELF supports them. Also, when was symbol preemption invented? Traditional shared library designs such as in IBM System/370, VMS, and Windows NT doesn't have it. As one who worked on optimizations in compilers, I came to hate symbol preemption because it prohibits many useful optimizations. ELF does provide a way to turn it off, but it's on by default--you have to explicitly declare symbols as protected or hidden via source language pragmas to get rid of it. -Paul W.

7 years, 4 months

Re: [TUHS] dead bstj unix link on wikipedia

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > anyone got a fix? Google quickly shows that Dennis' home page is now at: https://www.bell-labs.com/usr/dmr/www/ >From there, the CACM paper (HTML form) is at: https://www.bell-labs.com/usr/dmr/www/cacm.html Noel

7 years, 4 months

Novell, not SCO, found to own "Unix"

by Dave Horsfall

Time for another hand-grenade in the duck pond :-) Or as we call it down-under, "stirring the possum". On this day in 2010, it was found unanimously that Novell, not SCO, owned "Unix". SCO appealed later, and it was dismissed "with prejudice"; SCO shares plummeted as a result. As an aside, this was the first and only time that I was on IBM's side, and I still wonder whether M$ was bankrolling SCO in an effort to wipe Linux off the map; what sort of an idiot would take on IBM? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

The dollar symbol

by Dave Horsfall

On this day in 1778 businessman Oliver Pollock created the "$" sign, and now we see it everywhere: shell prompts and variables, macro strings, Perl variables, system references (SYS$BLAH, SWAP$SYS, etc), etc; where would we be without it? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 4 months

mail tuhs@minnie.tuhs.org

by Doug McIlroy

[TUHS] long lived programs (was Re: RIP John Backus > Every year someone takes some young hotshot and points them at some "impossible" thing and one of them makes it work. I don't see that changing. Case in point. We hired Tom Killian, a young high-energy physicist disenchanted with contributing to hundred-author papers. He'd done plenty of instrument programming, but no operating systems. So, high-energy as he was, he cooked up an exercise to get his feet wet. The result: /proc Doug

7 years, 4 months

Re: [TUHS] RIP John Backus

by Paul McJones

On 3/17/2018 12:22 PM, Arthur Krewat <krewat(a)kilonet.net> wrote: > Leave it to IBM to do something backwards. > > Of course, that was in 1954, so I can't complain, it was 11 years before > I was born. But that's ... odd. > > Was subtraction easier than addition with digital electronics back then? > I would think that they were both the same level of effort (clock > cycles) so why do something obviously backwards logically? Subtraction was done by taking the two's complement and adding. I suspect the CPU architect (Gene Amdahl -- not exactly a dullard) intended programmers store array elements at increasing memory addresses, and reference an array element relative to the address of the last element plus one. This would allow a single index register (and there were only three) to be used as the index and the (decreasing) count. See the example on page 97 of: James A. Saxon Programming the IBM 7090: A Self-Instructional Programmed Manual Prentice-Hall, 1963 http://www.bitsavers.org/pdf/ibm/7090/books/Saxon_Programming_the_IBM_7090_… The Fortran compiler writers decided to reverse the layout of array elements so a Fortran subscript could be used directly in an index register.

7 years, 4 months

daemons are not to be exorcised

by A. P. Garcia

Hi, The Hacker's Dictionary says that daemons were so named in CTSS. I'm guessing then that Ken Thompson brought them into Unix? I've noticed that more recent implementations of init have shunned the traditional terminology in favor of the more prosaic word "services". For example, Solaris now has SMF, the Service Management Facility, and systemd, the linux replacement for init, has services as well. It makes me a little sad, because it feels like some of the imaginativeness, fancifulness, and playfulness that imbue the Unix spirit are being lost.

7 years, 4 months

Fwd: long lived programs (was Re: RIP John Backus

by Clem Cole

[try-II] On Fri, Mar 23, 2018 at 6:43 AM, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 22 Mar 2018, at 21:05, Bakul Shah <bakul(a)bitblocks.com> wrote: > > > I was thinking about a similar issue after reading Bradshaw's > message about FORTRAN programs being critical to his country's > security. What happens in 50-100 years when such programs have > been in use for a long time but none of the original authors > may be alive? The world may have moved on to newer languages > and there may be very few people who study "ancient" computer > languages and even they won't have in-depth experience to > understand the nuances & traps of these languages well enough. > No guarantee that FORTRAN will be in much use then! Will it be > like in science fiction where ancient spaceships continue > working but no one knows what to do when they break? > > > My experience of large systems like this is that this isn't how they work > at all. The program I deal with (which is around 5 million lines naively > (counting a lot of stuff which probably is not source but is in the source > tree)) is looked after by probably several hundred people. It's been > through several major changes in its essential guts and in the next ten > years or so it will be entirely replaced by a new version of itself to deal > with scaling problems inherent in the current implementation. We get a new > machine every few years onto which it needs to be ported, and those > machines have not all been just faster versions of the previous one, and > will probably never be so. > > What it doesn't do is to just sit there as some sacred artifact which > no-one understands, and it's unlikely ever to do so. The requirements for > it to become like that would be at least that the technology of large-scale > computers was entirely stable, compilers, libraries and operating systems > had become entirely stable and people had stopped caring about making it do > what it does better. None of those things seems very likely to me. > > (Just to be clear: this thing isn't simulating bombs: it's forecasting the > weather.) > +1 - exactly my point. We have drifted a bit from pure UNIX, but I actually do think this is relevant to UNIX history. Once UNIX started to run on systems targeting HPC loads where Fortran was the dominate programming language, UNIX quickly displaced custom OSs and became the dominant target even if at the beginning of that transition as the 'flavor' of UNIX did vary (we probably can and should discuss how that happened and why independently -- although I will point out the UNIX/Linux implementation running at say LLNL != the version running at say Nasa Moffitt). And the truth is today, for small experiments you probably run Fortran on Windows on your desktop. But for 'production' - the primary OS for Fortran is a UNIX flavor of some type and has been that way since the mid-1980s - really starting with the UNIX wars of that time. As I also have said here and elsewhere, while HPC and very much its lubricant, Fortran, are not something 'academic CS types' like to study these days - even though Fortran (HPC) pays my and many of our salar ies . Yet it runs on the system the those same academic types all prefer - *i.e.* Ken and Dennis' ideas. The primary difference is the type of program the users are running. But Ken and Dennis ideas work well for almost all users and spans specific application market s. Here is a picture I did a few years ago for a number of Intel exec's. At the time I was trying to explain to them that HPC is not a single style of application and also help them understand that there two types of value - the code itself and the data. Some markets ( *e.g.* Financial) use public data but the methods they use to crunch it ( *i.e.* the code s ) are private, while others market segments might have private data (*e.g.* oil and gas) but different customers use the same or similar codes to crunch it. F or this discussion, think about how much of the code I sho w below is complex arithmetics - while much of it is searching google style , but a lot is just plain nasty math. The 'nasty math' that has not changed over the years and thus those codes are dominated by Fortran. [Note Steve has pointed out that with AI maybe the math could change in the future - but certainly so far, history of these markets is basically differential equations solvers]. As Tim says, I really can not see that changing and the reason (I believe) is I do not see any compelling economic reason to do so. Clem ᐧ ᐧ

7 years, 4 months

1978-03-25 - 2018-03-25: 40 years BSD Mail

by Steffen Nurpmeso

On this day in 1978 Kurt Shoens placed the following comment in def.h (the fork i maintain keeps it in nail.h): /* * Mail -- a mail program * * Author: Kurt Shoens (UCB) March 25, 1978 */ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

7 years, 5 months

Re: [TUHS] long lived programs (was Re: RIP John Backus

by Doug McIlroy

"The only thing I can think of is to use have programs that translate programs in todays languages to a common but very simple universal language for their "long term storage". May be something like Lamport's TLA+? A very tough job. " Maybe not so hard. An existence proof is Brenda Baker's "struct", which was in v7. It converted Fortran to Ratfor (which of course turned it back to Fortran). Interestingly, authors found their completely reorganized code easier to read than what they had written in the first place. Her big discovery was a canonical form--it was not a matter of taste or choice how the code got rearranged. It would be harder to convert the code to say, Matlab, because then you'd have to unravel COMMON statements and format strings. It's easy to cook up nasty examples, like getting away with writing behyond the end of an array, but such things are rare in working code. Doug

7 years, 5 months

Re: [TUHS] long lived programs

by Ron Natalie

A core package in a lot of the geospatial applications is a old piece of mathematical code originally written in Fortran (probably in the sixties). Someone probably in the 80's recoded the thing pretty much line for line (maintaining the horrendous F66 variable names etc.) into C. It's probably ripe for a jump to something else now. We've been through four major generations of the software. The original was all VAX based with specialized hardware (don't know what it was written in). We followed that on with a portable UNIX (but mostly Suns, but ours worked on SGI, Ardent, Stellar, various IBM AIX platofrms, Apollo DN1000's, HP, DEC Alphas). This was primarily a C application. Then right about the year 2000, we jumped to C++ on Windows. Subsequently it got back ported to Linux. Yes there are some modules that have been unchanged for decades, but the system on the whole has been maintained. The bigger issue than software getting obsoleted is that the platform needed to run it goes away.

7 years, 5 months

Re: [TUHS] Comments in early Unix systems

by Doug McIlroy

Thanks for the noweb story. A reward for straying off topic! Doug

7 years, 5 months

Re: [TUHS] daemons are not to be exorcised

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Going forward, I wish that people tried to be simple as they tackle the > more complicated problems we have. I have a couple of relevant quotations on my 'Some Computer-Related Lines' page: "Deliberate complexity is the mark of an amateur. Elegant simplicity is the mark of a master." -- Unknown, quoted by Robert A. Crawford "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." -- Alan Perlis "The most reliable components are the ones you leave out." -- Gordon Bell (For software, the latter needs to be read as 'The most bug-free lines of codqe are the ones you leave out', of course.) I remember watching the people building the LISP machine, and thinking 'Wow, that system is complex'. I eventually decided the problem was that they were _too_ smart. They could understand, and retain in their minds, all that complexity. Noel

7 years, 5 months

Masscomp - Real Time Unix (RTU) an early UNIX based system, the first commercial multiprocessor and was realtime

by Clem Cole

On Wed, Mar 21, 2018 at 7:50 PM, Larry McVoy <lm(a)mcvoy.com> wrote: > I was sys admin for a Masscomp with a 40MB disk Right an early MC-500/DP system - although I think the minimum was a 20M [ST-506 based] disk. On Wed, Mar 21, 2018 at 8:55 PM, Mike Markowski <mike.ab3ap(a)gmail.com> wrote: > I remember Masscomp ... it allowed data acquisition to not be swapped >> out. >> > Actually, not quite right in how it worked, but in practice you got the desired behavior. More in a minute. On Wed, Mar 21, 2018 at 9:00 PM, Larry McVoy <lm(a)mcvoy.com> wrote: > I remember the Masscomps we had fondly. The ones we had were 68000 based > and they had two of those CPUs running in lock step Not lock step ... 'executor' and 'fixor' -- actually a solution Forest Basket proposed at Stanford. The two implementations that actually did this were the Masscomp MC-500 family and the original Apollo. > ... because the > 68K didn't do VM right. I can't remember the details, it was something > like they didn't handle faults right so they ran two CPUs and when the > fault happened the 2nd CPU somehow got involved. > Right, it the original 68000 did not save the faulting address properly when it took the exception, so there was not enough information to roll back the from the fault and restart. The microcode in the 68010 corrected this flaw. > > Clem, what model was that? We called the dual 68000 board the CPU board and the 68010/68000 board the MPU. The difference was which chip was in the 'executor' socket and some small changes in some PALs on the board to allow the 68010 to actually take the exception. Either way, the memory fault was processed by the 'fixor'. BTW: the original MC-500/DP was a dual processor system, so it has 4 68000 just for the 2 'cpu boards -- i.e. an executor and fixor on each board. The later MC-5000 family could handle up to 16 processor boards depending the model (MC-5000/300 was dual, MC-5000/500 up to 4 and the MC-5000/700 up to 16 processor boards). Also for the record, the MC-500/DP and MC-5000/700 predate the multiprocessor 'Symmetry System' that Sequent would produce by a number of years). The original RTU ran master/slave (Purdue VAX style) for the first generation (certainly through RT 2.x and maybe 3.x). That restriction was removed and a fully symmetric OS was created, as we did the 700 development. I've forgotten which OS release brought that out. A few years later Stellix, while not in direct source development a child, had the same Texieria/Cole team as RTU - was always fully symmetric - i.e. lesson learned. > And can you provide the real version of what I was trying say? > Sure ... soon after Motorola released the 68000, Stanford's Forest Baskett in a paper I have sadly lost, proposed that the solution the 68000's issue of not saving enough information when an illegal memory exception occured, was to instead of allowing the memory exception, return 'wait states' to the processor - thus never letting it fault. More specifically, the original microprocessor designs had a fixed time that the memory system needed to respond on a read or write cycle that was defined by the system clock. I don't have either Motorola 68000 or MOS 6502 processor books handy, but as a for instance IIRC on a 1 Mhz MOS 6502 you had 100 nS for this operation. Because EPROMs of the day could not respond that fast (IIRC 400ns for a read), the CPU chip designers created a special 'WAIT' signal that would tell the processor, to look for the data in on the next clock tick (and the wait signal could be repeated for each tick for an indefinite wait if need be). *i.e. *in effect, when running from ROM a 6502 would run at .25MHz if it was doing direct fetches from something like an Intel 1702 ROM on every cycle. Similarly, early dynamic RAM, while faster that ROM, had access issues with needing to ensure the refresh cycles and the access cycles aligned. Static RAMs which were fast, did not have these problems and could directly interface to processor, but static RAMs of the day were the quite expensive chips (5-10 times) in comparison to DRAM cost, so small caches were built to front end the memory system. Hence, the HW 'wait state' feature became standard (and I think is still supported in todays processors), since it allows the memory system speed and the processor to work at differing rates. i*.e.* the difference in speed could be 'biased' to each side -> processor vs memory. In his paper, Forest Basket observed that if a HW designer used the wait state feature, a memory system could be built that refreshed the cache using another processor, as long as the second processor that was 'fixing up' the exception ( i.e. refilled the cache with proper data) could be ensured it never had a memory fault. Basket's idea was exactly how both the original Apollo and Masscomp CPU boards were designed. On the Masscomp CPU board, there was a 68000 that always ran from a static ram based cache (which we called the 'executor.' If it tried to access a memory location that was not yet in cache, or if it was a legal memory access, the memory system sent wait states until the cache was refilled as you might expect. If the location was illegal, the memory system also return a error exception as expected. However, it was legal address but not yet in memory, the second 6800 (the 'fixor') was notified of desire to access that specific memory location and the fixor ran the paging code to put the page into the live memory. Once the cache was properly set up, then the executor could be released from wait state and instruction allowed to complete. When Motorola released the 68010 with the internal fixes that would allow an faulting instruction to be restarted, Masscomp revised the CPU board (creating the MPU board) to install a 68010 in the executor socket and changed a few PALs in the memory system on the board. If a memory address was discovered to be legal, but not in memory, the executor (now a 68010) was allowed to returned a paging exception and stack was saved appropriately, and the executor did a context switch to different process - allow the executor to do something useful while the fixor processed the fault. Although we now had to add kernel code for the executor processor to return from restart at the fault instruction on a context switch back to the original process. The original fixor code did not need to be changed, other than to remove need to clearing of the 'waiting flop' for that restarted the executor. [RTU would detect which board was plugged into a specific system automatically so it was an invisible change to the end user - other than you got a few percent performance back if there was a lot of page faults in your application since the executor never wait stated]. As for the way real time and analog I/O worked that Mike commented upon. Yes, RTU - Real Time Unix supported features that could guarantee that I/O would not be lost from the DMA front end. For those not familiar with the system, it was a 'federated system' with a number of subsystems: the primary UNIX portion that I just described and then a number of other specialized processors that surrounded it for specific tasks. This architecture was chosen because the market we were attacking was a scientific laboratory and in particular real-time oriented - for instance, some uses were Mass General in the Cardiac ward, on board ever EWACS plane to collect all and retain all signals during any sortie [very interesting application], NASA used 75 of them in Mission Control to be the 'consoles' you see on TV, *etc *[ which have only recently be replaced by PCs, as some were still in use at least 2 years ago when I was last in Houston]. So besides the 2/4 68000s in the main UNIX system, their was another dedicated 68000 running a graphics system on the graphics board, another 80186 running TCP/IP, and an AM2900 bit slices processor called Data Acquisition and Control Processor (DA/CP) - which Mike hinted, as well as 29000's for the FP unit and Array processor functionality. Using ther DA/CP, in 1984, and MC-500 system could handle multiple 1MHz analog 16 bit signals - just by sampling them -> in fact, a cute demo at the Computer Museum in Boston just connected a TV camera to the DA/CP and without any special HW, it could 'read' the video signal (if you normally have a connection a TV camera, it usually takes a bunch of special logic to interface to the TV signals -- in this case it was just SW in the DA/CP). The resultant OS was RTU, were we had modified a combined 4.1BSD and System III 'unices' (later up dated to 4.2 and V.2] to support RT behaviors, with pre-emption, ASTs [which I still miss - a great idea but nicer than traditional UNIX signals], async I/O, *etc*.. Another interesting idea was the concept of 'universes' that allowed on a per user basis, to see a BSD view of the system or an System V view]. One of the important things we did in RTU was rethink the file system (although only a little then). Besides all the file types and storage schemes you have with UFS, Masscomp added support for an pre-allocated extent based files (like VMS and RSX) and then created a new file type called contiguous file that used it [by the time of the Stellar and Stellix, we just made all files extent based and got rid of the special file type - *i.e.* looked like UFS to the user, but under the covers was fully extend based]. So under RTU, once we had preallocated files that we knew were on contiguous blocks, we could make all sorts of speed ups and guarantees that traditional UNIX can not because of the randomized location of the disk blocks. So the feature that Mike was using, was actually less a UNIX change and did not actually use the preemption and other types of RT features. We had added the ability for the DA/CP to write/read information directly from the disk without OS getting in the way - (we called it Direct to Disk IO). An RTU application created a contiguous file large enough on disk to store the data the DA/CP might receive - many megabytes typically - but the data itself was never passed thru or stored in the UNIX buffer cache *etc*. The microcode of the DA/CP and the RTU disk driver could/would cooperate and all kernel or user processing on the UNIX side was by-passed. Thus, when the real time data started to be produced by the DA/CP (say the EWACS started getting radio signals on one of those 16 bit analog converters) the digital representation of those analog signals were stored in the users file system independent of what RTU was doing. The same idea, by the way was why we chose to run IP/TCP on a co-processor. So much of network I/O is 'unexpected,' we could potentially lose the ability to make real-time guarantees. But keeping all the protocol work outside of UNIX, the network I/O just operated on 'final bits' at the rate that was right for it. As an interesting aside, this worked until we switched to a Motorola 68020 at 16 Mhz or 20Mhz (whatever it was I've forgotten now) in the MC-5000 system. The host ended up be so much faster than the 80186 in the ethernet coprocessor board. We ended up offering a mode were they swapping roles and just used the '186 board as a very heavily buffered ethernet controller, so we could keep protocol processing very low priority compared to other tasks. However if we did that, it did mean some of the system guarantees had to be removed. My recollection is that only a couple of die hard RT style customers, ended up continuing to use the original networking configuration. Clem

7 years, 5 months

daemons are not to be exorcised/Comments in code

by David

> From: Dave Horsfall <dave(a)horsfall.org> > Yep, and I'm glad that I had bosses to whom I didn't have to explain why > my comments were so voluminous. > > And who first said "Write your code as though the next person to maintain > it is a psychotic axe-wielding murderer who knows where you live"? I've > often thought that way (as the murderer I mean, not the murderee). > > I'd name names, but he might be on this list... > I’ve always said that the person was a ‘reformed’ axe-wielding murderer who knows where you live. Please, a little decorum. W.R.T. comments in code, and a bit of Unix, when I taught Unix Systems programming at UCSD one of my students wanted to use his personal computer for the programming. I didn’t care as long as it would pass the tests I ran after the fact. After his second homework was turned in, I stopped looking at his code or even running it, as the comment blocks were just so well done. Nary a comment in the function itself, just a block before each one very clearly explaining what was happening. David

7 years, 5 months

Re: [TUHS] Comments in early Unix systems

by Doug McIlroy

"I was told in school (in 1985) that if I was ever lucky enough to have access to the unix source, I'd find there were no comments. The reason, I was told at the time, was that comments would make the source code useful, and selling software was something AT&T couldn't do due to some consent decree." I can't speak for SYS V, but no such idea was ever mentioned in Research circles. Aside from copyright notices, the licensing folks took no interest in comments. Within rsearch there was tacit recognition of good coding style--Ken's cut-to-the-bone code was universally admired. This cultural understanding did not extend to comments. There was disparagement for the bad, but not honor for the good. Whatever comments you find in the code were put there at the author's whim. My own commenting style is consistent within a project, but wildly inconsistent across projects, and not well correlated with my perception of the audience I might be writing for. Why? I'm still groping for the answer. For imoortant code, custom is to describe it in a separate paper, which is of course not maintained in parallel with the code. In fact, comments are often out of date, too. Knuth offered the remedy of "literate programming", which might help in academic circles. In business, probably not. Yet think of the possibility of a "literate spec", where the code grows organically with the understanding of what has to be done. Doug

7 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS