gnu@hoptoad.uucp (John Gilmore) (09/04/86)
[Followups should go only to net.micro.68k.] > UNIX and the MC68000 (by Andrew L. Rood, Robert C. Cline, Jon Brewster) > The powerful yet simple programmer's model offered by the 68000's > architecture makes UNIX implementation easy. Flame on. This article is the worst one I've seen in BYTE in a long time. A shame, since it's probably the one closest to the interests of us on net.micro.68k. The authors work for HP in Corvallis, Oregon; maybe they are on the net. If so, guys, stand up and defend your article -- if you can. Here's a sample paragraph from page 198: "COPROCESSORS The MC68000 family allows for multiple CPU environments. In the UNIX environment there is the possibility for much parallel processing if multiple processors are available. The MC68000 bus operates asynchronously. This aids in configuring buses with a multimaster capability that support multiple CPUs using the same memory and peripherals. Many types of coprocessors are common to UNIX implementations, including floating-point coprocessors, graphics coprocessors, and DMA (direct memory access) processors. Because UNIX is a multitasking system with multiple processes executing at any time, the operating system easily manages multiprocessor envionments." A few of the errors in just this paragraph: * Having an asynchronous bus has nothing to do with whether it supports multiple masters. * The authors are confused among coprocessors, multiprocessing, DMA, and multitasking. A coprocessor as the word is typically used means a specialized chip which executes some instructions for the CPU, e.g. the float instructions. Multiprocessing refers to having two or more identical or similar CPUs working in parallel, as on a Sequent machine or on large ibm "MP" machines. DMA (Direct Memory Access) allows I/O devices to read or write memory without CPU intervention. Multitasking means having more than one program appearing to run at once, as on all Unix machines. * Being able to do one of the above does not make the rest easy. * The 68000 does not provide direct support for any of these; they are implemented by software and/or external hardware. (The 68020 directly supports coprocessors, but they are talking about the 68000.) * Unix has a lot of trouble with multiprocessor environments. People who run Unix on MP hardware did a lot of hard work on Unix to get there. The above paragraph, while worse than most, is typical. The authors demonstrate how little they know about Unix and system design throughout the article. I thought BYTE was refereed and edited better than this, but it isn't. With people like this "explaining" Unix to the masses, no wonder people don't understand it. Flame off. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
jimomura@lsuc.UUCP (Jim Omura) (09/05/86)
I post this with some trepidation. Again, I haven't read the article in question, and am simply posting doubts about the criticism being voiced so far. At that, I have never written an OS myself and am new to the 68000 processor as a real owner, having just bought my Atari 1040ST and having 2 more computers in the planning stages, but delayed due to financial consi- derations. Anyway, let's see here: In article <1058@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >> UNIX and the MC68000 (by Andrew L. Rood, Robert C. Cline, Jon Brewster) >> The powerful yet simple programmer's model offered by the 68000's >> architecture makes UNIX implementation easy. > >Flame on. > >This article is the worst one I've seen in BYTE in a long time. A shame, >since it's probably the one closest to the interests of us on net.micro.68k. >The authors work for HP in Corvallis, Oregon; maybe they are on the net. >If so, guys, stand up and defend your article -- if you can. > >Here's a sample paragraph from page 198: > >"COPROCESSORS > >The MC68000 family allows for multiple CPU environments. In the UNIX >environment there is the possibility for much parallel processing if >multiple processors are available. The MC68000 bus operates >asynchronously. This aids in configuring buses with a multimaster >capability that support multiple CPUs using the same memory and >peripherals. Many types of coprocessors are common to UNIX >implementations, including floating-point coprocessors, graphics >coprocessors, and DMA (direct memory access) processors. Because UNIX >is a multitasking system with multiple processes executing at any time, >the operating system easily manages multiprocessor envionments." > >A few of the errors in just this paragraph: > >* Having an asynchronous bus has nothing to do with whether it supports >multiple masters. John, are you sure about that? I would think that an asynchronous with a processor like the 68000 would be advantageous, first in any multiple processor environment because the processor tends to need the bus at irregu- lar intervals. If processing was synchronous then a rotation scheme would appear to me to be the best way to impliment multiple bus masters. Because it's difficult to predict when the bus will be needed on the widely varied times in the rich 68K instruction set, a straight rotation looks very inefficient to me and thus multiple bus masters would not be very practical. The asynch bus looks to me to be a fairly advantageous thing to have. Am I wrong in this theory? > >* The authors are confused among coprocessors, multiprocessing, DMA, >and multitasking. A coprocessor as the word is typically used means a >specialized chip which executes some instructions for the CPU, e.g. the >float instructions. Multiprocessing refers to having two or more >identical or similar CPUs working in parallel, as on a Sequent machine Sorry. I can't see anything here to criticise. You say that the word "coprocessor" has a "common" usage. So what? It *is* also used the way the authors used it. They weren't wrong. For example, in one of my 68000 computers (half built) I have 2 Z-80 Co-processors one of which is an alternative main processor and the other is a keyboard processor. I can write programs to *use* them as you are saying, but I need not even come that close to conforming with your conception. Actually, the keyboard Z-80 comes conceptually closer to your description of multi-processing since it runs off on it's own until it needs the bus and throws an interrupt. The other Z-80, on the otherhand shares the RAM (not dual ported) with the 68000 and cannot run at the same time. >or on large ibm "MP" machines. DMA (Direct Memory Access) allows I/O >devices to read or write memory without CPU intervention. Multitasking >means having more than one program appearing to run at once, as on all >Unix machines. I don't see any evidence that they don't know any of the above. > >* Being able to do one of the above does not make the rest easy. That's a pretty broad statement. I'm not convinced that the paragraph you quoted necessarily meant each and every possibility you have denied. Nor am I convinced you're necessarily right. It would seem to me that a multi-tasking environment would be a good way to utilize co-processing and/or multi-processing. In fact, any multi-processing is multi-tasking in the broad usage of the word. > >* The 68000 does not provide direct support for any of these; they are >implemented by software and/or external hardware. (The 68020 directly >supports coprocessors, but they are talking about the 68000.) Whaaa? Hey, now the paragraph seemed to start off talking about the 68K family generally. They may have mentioned the 68000 at one point there specifically, but I think you're reading it a bit tighter than is called for. Relax a bit, go have a beer and read the article in a more relaxed frame of mind. (Watch this. I'll read the article and start screaming even louder. :-) > >* Unix has a lot of trouble with multiprocessor environments. People >who run Unix on MP hardware did a lot of hard work on Unix to get >there. (No argument. Then again, I never thought Unix was wonderful anyway.) > >The above paragraph, while worse than most, is typical. The authors >demonstrate how little they know about Unix and system design >throughout the article. I thought BYTE was refereed and edited better >than this, but it isn't. With people like this "explaining" Unix to >the masses, no wonder people don't understand it. Flame off. > >-- > May the Source be with you! -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
mitch@well.UUCP (Mitchell Waite) (09/06/86)
Keywords: John I couldn't agree more with you. I found the 68000 artcle confusing in some ways and great in others, but I found it a bit self serving. There was not a word of what is WRONG with the 68000 for Unix (it isn't perfect) or what its limitations are? It might have been better if BYTE used a smaller 68000 purchaser than Tektronix for its source for authors. I also felt that the book review was crummy, as it left out some of the greatest boo for the 68000 and Macintosh assembly language.
phil@amdcad.UUCP (Phil Ngai) (09/06/86)
In article <1327@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >> >>* Having an asynchronous bus has nothing to do with whether it supports >>multiple masters. > > John, are you sure about that? I would think that an asynchronous >with a processor like the 68000 would be advantageous, {I'm a hardware designer. The first thing I do when I get an asynchronous signal is run it into a synchronizer. I run the output of that into another synchronizer. The problem with asynchronous signals is that the circuitry receiving it may once in a while be unable to decide what it saw. What happens then is a matter of luck. Often it will oscillate for a while. This is called a metastable state. This is a problem with all asynchronous systems. It is inherent in the nature of the universe. What you can do is reduce the probability of it happening to acceptable levels. This is done with two methods. 1) Allow the circuit enough time to decide what came in before depending on its output. 2) Use fast logic which can decide quickly. The double synchronizer allows the first synchronizer to have time to decide before the second synchronizer samples it. Studies were done by a University in the mid-west (I think, anyone remember the name?) which found a range of roughly 10E10 (plus or minus a lot, I only remember it was a LARGE number) among the various logic families' probability of going metastable. >first in any multiple >processor environment because the processor tends to need the bus at irregu- >lar intervals. If processing was synchronous then a rotation scheme would >appear to me to be the best way to impliment multiple bus masters. Because >it's difficult to predict when the bus will be needed on the widely varied >times in the rich 68K instruction set, a straight rotation looks very >inefficient to me and thus multiple bus masters would not be very practical. No, what you do is give the bus to the first one asking. If more than one asks you have several methods available. The easiest, but not very fair, is to rank the processors in a static priority. A more fair method is to rotate the priority among the processors. But since you are only arbitrating among the processors who want the bus, there is no inefficiency. There are no time slots which go wasted while a processor is waiting as you imply in your rotation scheme. >Nor am I convinced you're necessarily right. It would seem to me that a >multi-tasking environment would be a good way to utilize co-processing >and/or multi-processing. In fact, any multi-processing is multi-tasking >in the broad usage of the word. Faulty logic. A Cray is a computer but that does not mean a computer is a Cray. Multi-processing is multi-tasking but multi-tasking is not multi-processing. To me, at least, coprocessor implies a very tight relationship between the main and the coprocessor. The 8086/8087 fit this definition. A 68000 and a Z80 do not. Your keyboard Z80 is a peripheral controller. I would probably call the other Z80 an auxilary processor. -- Rain follows the plow. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/09/86)
> Summary: Are you sure? > >> >>* Having an asynchronous bus has nothing to do with whether it supports >>multiple masters. > > John, are you sure about that? I would think that an asynchronous > with a processor like the 68000 would be advantageous, first in any multiple > processor environment because the processor tends to need the bus at irregu- > lar intervals. If processing was synchronous then a rotation scheme would > appear to me to be the best way to impliment multiple bus masters. Because > it's difficult to predict when the bus will be needed on the widely varied > times in the rich 68K instruction set, a straight rotation looks very > inefficient to me and thus multiple bus masters would not be very practical. > The asynch bus looks to me to be a fairly advantageous thing to have. Am I > wrong in this theory? Yes. Except for the TAS instruction, all 68000 bus cycles are the same, the 68000 requiring bus access during the last 2 of the 4 clock cycles, and the cycle either being read or write. The main advantage of the 68000's asynchronous capabilities is that any kind of slow memory can be read without any special hardware considerations. Put another way, you can run your 68000 as fast as the fastest memory in the system and still be able to access any slower memory with no penalty. Synchronous processors can do the same thing, but they usually have to be explicitly told to wait for the memory output (like in the Z-80 and the 6502). If, for some reason, you ran a system of several 68000s that were mutually asynchronous, you could call the asynchronous bus capabilities an advantage for multiprocessing, but most multiprocessing schemes would enforce at least some degree of mutual sychronization between processors. >>* The 68000 does not provide direct support for any of these; they are >>implemented by software and/or external hardware. (The 68020 directly >>supports coprocessors, but they are talking about the 68000.) > > Whaaa? Hey, now the paragraph seemed to start off talking about the > 68K family generally. They may have mentioned the 68000 at one point there > specifically, but I think you're reading it a bit tighter than is called > for. There's probably that confusion, since the magazine is concentrating, in this issue, on the 68000 specifically. The 68000 doesn't have built-in support for the 68881 dedicated math coprocessor as does the 68020, that's true, but it does support other 68000's in a multiprocessing environment via the aforementioned TAS instruction, which allows the 68000 to examine a bit flag without any possible intervention from an alternate processor, since it does read-modify-write in one cycle. Incidently, as far as I've heard, none of the top 3 popular 68000 systems support the TAS instruction. The AMIGA executes a read cycle for TAS; I believe that it will crash either the Atari ST or Apple MAC. >> >>The above paragraph, while worse than most, is typical. The authors >>demonstrate how little they know about Unix and system design >>throughout the article. I thought BYTE was refereed and edited better >>than this, but it isn't. With people like this "explaining" Unix to >>the masses, no wonder people don't understand it. Flame off. >> >>-- > James Omura, Barrister & Solicitor, Toronto > ihnp4!utzoo!lsuc!jimomura > Byte Information eXchange: jimomura > (416) 652-3880 I didn't yet read this article either, but it does seem to me as well, overall, that BYTE is loosing some of its past excellence, especially in the areas of technical excellence. Its let numerous letter slip past that went beyond misleading to the realm of "completely wrong", and on various subjects that BYTE had the technical knowledge to correct or not publish in the first place. They aren't responsible for the material submitted to them, but they certainly are responsible for the content of anything they decide to publish. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
tim@ism780c.UUCP (Tim Smith) (09/11/86)
In article <710@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > Incidently, as far as I've heard, none of the top 3 popular 68000 > systems support the TAS instruction. The AMIGA executes a read > cycle for TAS; I believe that it will crash either the Atari ST > or Apple MAC. Sounds like someone is using AS to de-assert DTACK rather than UDS and LDS. Is this correct? In the micro lab class I took when I was a student at Caltech, about half the 68k systems students designed had this problem. -- I admit it! I don't believe in Mary Worth! I Lied! HaHaHaHaHaHa!!!!!! Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
pavlov@hscfvax.UUCP (840033@G.Pavlov) (09/12/86)
In article <1058@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > > UNIX and the MC68000 (by Andrew L. Rood, Robert C. Cline, Jon Brewster) > > The powerful yet simple programmer's model offered by the 68000's > > architecture makes UNIX implementation easy. > > Flame on. > < much (most likely) legitimate criticism, including .... > > * Unix has a lot of trouble with multiprocessor environments. People > who run Unix on MP hardware did a lot of hard work on Unix to get > there. > I don't claim to know much about multiprocessors, coprocessors, etc. However, I was responsible for an HP9000 system for several years, a system which can include up to 3 processors, running under HP's Unix implementation, HP-UX. This system was rock-solid (no software crashes; one 7-month stint between hardware failures), the multiprocessor configuration was completely transparent, and the "power" increment of each cpu was exactly as advertised. So I would say that someof the personnel at HP, at least, do have a good understanding of multiprocessor configurations running under Unix. greg pavlov, fstrf, amherst, ny
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/12/86)
> > In article <710@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >> Incidently, as far as I've heard, none of the top 3 popular 68000 >> systems support the TAS instruction. The AMIGA executes a read >> cycle for TAS; I believe that it will crash either the Atari ST >> or Apple MAC. > > Sounds like someone is using AS to de-assert DTACK rather than UDS and > LDS. Is this correct? > > In the micro lab class I took when I was a student at Caltech, about half > the 68k systems students designed had this problem. > -- > I admit it! I don't believe in Mary Worth! I Lied! HaHaHaHaHaHa!!!!!! > > Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 > Delphi or GEnie: mnementh I'm not sure if they look at /AS or /UDS and /LDS, but that's not the main reason. In the Amiga at least, the video processors share half of the memory cycle time (S0-S3). There's not enough time on the DRAM bus for a Read-Modify-Write cycle. While the ST and MAC system aren't doing things as complex with their video displays, they do share the bus and probably have similar memory constraints. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
andy@hp-pcd.UUCP (andy) (09/12/86)
>Flame on. > >This article is the worst one I've seen in BYTE in a long time. A shame, >since it's probably the one closest to the interests of us on net.micro.68k. >The authors work for HP in Corvallis, Oregon; maybe they are on the net. >If so, guys, stand up and defend your article -- if you can. Yes, HP Corvallis is on the net and listening. Sorry you were so disappointed about the article. Perhaps BYTE is not a good magazine for you to continue to read. > >Here's a sample paragraph from page 198: > >"COPROCESSORS > >The MC68000 family allows for multiple CPU environments. In the UNIX >environment there is the possibility for much parallel processing if >multiple processors are available. The MC68000 bus operates >asynchronously. This aids in configuring buses with a multimaster >capability that support multiple CPUs using the same memory and >peripherals. Many types of coprocessors are common to UNIX >implementations, including floating-point coprocessors, graphics >coprocessors, and DMA (direct memory access) processors. Because UNIX >is a multitasking system with multiple processes executing at any time, >the operating system easily manages multiprocessor envionments." > >A few of the errors in just this paragraph: > >* Having an asynchronous bus has nothing to do with whether it supports >multiple masters. While it is true that all forms of machine exist (i.e. asynchronous bus with/without multiple masters; synchronous bus with/without multiple masters); I do not agree that the form of bus synchronization and the implementation of multiple masters are unrelated. As per the opening comments of the article the concern is with actual implementation, not theory. My belief is that multiple bus masters are easier to implement and configure in an asynchronous bus environment. This point is debatable. However, in defense of our article keep in mind that whatever viewpoint is championed, it must be so championed in at most two paragraphs. The BYTE editors specifically requested that we condense a more complete discussion of coprocessors into the two paragraphs of this section. > >* The authors are confused among coprocessors, multiprocessing, DMA, >and multitasking. A coprocessor as the word is typically used means a >specialized chip which executes some instructions for the CPU, e.g. the >float instructions. Multiprocessing refers to having two or more >identical or similar CPUs working in parallel, as on a Sequent machine >or on large ibm "MP" machines. DMA (Direct Memory Access) allows I/O >devices to read or write memory without CPU intervention. Multitasking >means having more than one program appearing to run at once, as on all >Unix machines. First, the authors are not confused (they may be incorrect, but not confused). In this section I am using some of the terminology of the OSU EE-CE department graduate architecture sequence which I taught last quarter. Having difficulty compressing a full quarter's material into one paragraph, I opted to use only the term coprocessor (note that multiprocessing, multiprocessors, slave processor, I/O processor, tightly/loosely coupled processors, array processor etc etc; are not used at all in the article). > >* Being able to do one of the above does not make the rest easy. Yes, being able to do one does not necessarily imply that others are easy. However in real world design those design characteristics which support one are often useful in support of others. Again, Your point may be true in the abstract theory of it, but in reality these different types of multiple processor designs involve some similar design problems. Remember that the thrust of this article is not coprocessors, and it is not UNIX, the thrust is 68000 family architecture. We were informed when writing the paper that there would be another article on multiple processor configurations in the same issue, therefore we were asked not to go into the topic more than briefly. > >* The 68000 does not provide direct support for any of these; they are >implemented by software and/or external hardware. (The 68020 directly >supports coprocessors, but they are talking about the 68000.) See previous note regarding this. This article is talking about the 68000 family, including the 68020. Please read more carefully. > >* Unix has a lot of trouble with multiprocessor environments. People >who run Unix on MP hardware did a lot of hard work on Unix to get >there. I would agree that UNIX has a lot of trouble with some multiprocessor environments. However, my contention is that because UNIX presumes a multiple process model of computation, it is easier to make use of multiple processors than it is in a single tasking (or single process) environment. The HP series 500 for example is a multiprocessor environment (using your terminology where multiprocessor implies several identical processors) which runs UNIX and effectively uses processors on a per process basis. The HP series 200 machines use 68020s with 68881s (presumably a correct use of the term 'coprocessor' in your usage) and implement UNIX using both processors without taking advantage of the multiple process nature of UNIX. The 68881 processor does not make UNIX implementation difficult however. Perhaps you are speaking of classical array processors or other tightly coupled multi-processor systems which have difficulty implementing UNIX so as to gain from the presence of multiple processors. > >demonstrate how little they know about Unix and system design >throughout the article. I thought BYTE was refereed and edited better >than this, but it isn't. With people like this "explaining" Unix to >the masses, no wonder people don't understand it. Flame off. > >-- >John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa > May the Source be with you! >/* ---------- */ Flame on- Why be so disparaging of the article yet provide no substance to your disparaging remarks. If you found the prose or grammar of the article to be sub standard then please let me know via net mail. If you have some real substanitive complaints then what are they? I am not familiar with BYTE's general policies, however this article was not refereed, it was solicited. The article outline and contents were agreed to with the input of BYTE technical editors. We wrote the article after being requested to do so by BYTE. This article is NOT explaining UNIX! Please read more carefully. The BYTE staff specifically requested that we NOT attempt to explain UNIX. Please keep in mind that the general BYTE audience is very large and NOT as technically expert as the readership of this notes group. I believe the article is well written and accomplishes precisely what it attempts. You seem to be dissatisfied because the article is not a highly technical, completely comprehensive UNIX summary. The article was never intended to be. The majority of BYTE readership (as represented to us by the BYTE technical editors) is interested in precisely the type of article we generated. The intent was not to be highly UNIX technical, but rather to focus on the 68k family. The intent was to address a less sophisticated group of readers and provide an initial view of some UNIXisms and how they relate to the 68k. I do NOT see merit in your complaints with my coprocessor paragraph. You have isolated two areas which are moot, however you have jumped to your own conclusions about what the paragraph implies and then contradicted your own conclusions. If you have some items of substance in which the article is incorrect, then let's hear them. Not items where your conclusions are incorrect, items which are part of the article. Your comments regarding competance as UNIX implementors and system design are not supported. We do UNIX implementation and 68k family system design here in Corvallis. HP has great competance in both fields. We produce real, innovative products which work and sell. That is sufficient proof of our competance for me. Go get a beer and mellow-out, John. -Flame off Andy Rood ... {hplabs,hpfcla}!hp-pcd!andy
srm@iris.berkeley.edu (Richard Mateosian) (09/30/86)
>>I thought BYTE was refereed and edited better than this, but it isn't. > I am not familiar with BYTE's general policies, however this article > was not refereed, it was solicited. The article outline and contents > were agreed to with the input of BYTE technical editors. We wrote > the article after being requested to do so by BYTE. > I had a similar experience. I wrote an article for the Jan 1984 BYTE ("1984 Is the Year of the 32-Bit Microprocessor"). It was solicited, and they printed what I sent them almost verbatim. Richard Mateosian ...ucbvax!ucbiris!srm 2919 Forest Avenue 415/540-7745 srm%ucbiris@Berkeley.EDU Berkeley, CA 94705