mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/15/91)
[Still trying to push this back to comp.sys.amiga.misc - mwm]
In article <1991Jan11.081137.17529@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes:
There must be 2 kinds of tasks possible in a "true" multitasking system.
One kind of task is the kind that Amiga and Multifinder support, multiple
applications. The second is one that multifinder does not support which
is a task that is part of an application and is spawned while the
application runs and terminates sometime before (or right when) the
application quits.
The only thing interesting you might be talking about is lightweight
processes. The only reason those are interesting is because they're
cheaper than normal processes. In any case, they have nothing to do
with the topic at hand.
The Amiga also has a 3rd kind of multitasking. There are 3 CPUs in the
Amiga if you consider the Blitter and the Copper. All 3 of these CPUs can
be executing programs at the same time. In MOST cases, the 680x0 can still
execute and perform its Exec() multitasking while the other CPUs are
executing.
That's not multitasking; multiprocessing is closer to the meaning of
the term. It's _still_ got nothing to do with the topic at hand.
This definition of *true* multitasking should be good enough to shut up your
average anal-retentive Mac evangilist :)
This has something to do with the topic at hand - it's the kind of
asinine statement that gives Amiga owners a bad name, and the attitude
that makes the phrase "true multitasking" something to be avoided.
Aforementioned Mac evangilist will go away, and quit wasting his time
trying to get information into your head. Anyone else in the vicinity
will go away, and be wary of anyone who uses an Amiga from then on.
<mike
--ben@servalan.uucp (Ben Mesander) (01/15/91)
In article <MWM.91Jan14113155@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >[Still trying to push this back to comp.sys.amiga.misc - mwm] I hate to say it Mike, but a thread this silly belongs in .advocacy.
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/18/91)
In article <MWM.91Jan14113155@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >[Still trying to push this back to comp.sys.amiga.misc - mwm] > >In article <1991Jan11.081137.17529@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > There must be 2 kinds of tasks possible in a "true" multitasking system. > One kind of task is the kind that Amiga and Multifinder support, multiple > applications. The second is one that multifinder does not support which > is a task that is part of an application and is spawned while the > application runs and terminates sometime before (or right when) the > application quits. > >The only thing interesting you might be talking about is lightweight >processes. The only reason those are interesting is because they're >cheaper than normal processes. In any case, they have nothing to do > with the topic at hand. It has everything to do with the discussion at hand. Without what you call lightweight processes, you have something less than what you have with them. Without lightweight processes, you DON'T HAVE true multitasking. True multitasking is what the posting was about that this response was made to. Lightweight processes allow you to have a second task that writes graphics to the screen while another manipulates pulldown menus. Lightweight processes allow a hard disk backup program to read from hard disk, compress, and write to floppy (that is 1 application plus 2 lightweight processes) in the most efficient manner possible. It allows applications to take advantage of the multitasking environment. > > The Amiga also has a 3rd kind of multitasking. There are 3 CPUs in the > Amiga if you consider the Blitter and the Copper. All 3 of these CPUs can > be executing programs at the same time. In MOST cases, the 680x0 can still > execute and perform its Exec() multitasking while the other CPUs are > executing. > >That's not multitasking; multiprocessing is closer to the meaning of >the term. It's _still_ got nothing to do with the topic at hand. > Yes it is multiprocessing, but when you consider that these are things normally done by the CPU on other computers, it becomes a form of multitasking, too. > This definition of *true* multitasking should be good enough to shut up your > average anal-retentive Mac evangilist :) > >This has something to do with the topic at hand - it's the kind of >asinine statement that gives Amiga owners a bad name, and the attitude >that makes the phrase "true multitasking" something to be avoided. >Aforementioned Mac evangilist will go away, and quit wasting his time >trying to get information into your head. Anyone else in the vicinity >will go away, and be wary of anyone who uses an Amiga from then on. > > <mike >-- Call me an anal retentive amiga user because I am one. This thread is not just a bunch of Amiga guys having an intelligent discussion about various kinds of multitasking. It is Amiga guys explaining the difference between TRUE multitasking, which the Amiga has, and a switcher (albeit a glorious one) which the Mac has. No matter what we (Amiga) say, they (Mac) don't wanna believe that what they have is any less than what we have. By the way, I did not invent the term anal-retentive Mac evangilist. I just thought it was humorous (note the :) in my post) and it does describe most of the most gung-ho mac enthusiasts I run into. However obnoxious I can find such enthusiasts to be, I know I am just as obnoxious about the Amiga. And I do respect a person for being passionate about things he likes, even a mac. What I don't like about the Mac is that it is made by apple. I find the company policy of not selling ROMs anymore to be a vicious and malicious business practice. I find the pricing and performance of their machines and software to be poor. I find that those who support the company by buying their product are doing more harm than they know.
torrie@cs.stanford.edu (Evan J Torrie) (01/19/91)
mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: >[lots of stuff deleted] >What I don't like about the Mac is that it is made by apple. I find the >company policy of not selling ROMs anymore to be a vicious and malicious >business practice. As a matter of interest, does Commodore sell their ROMs and custom chips (Blitter, Copper) etc to anybody?? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Dear Fascist Bully Boy, Give me some money, or else. Neil. P.S. May the seed of your loins be fruitful in the womb of your woman..."
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/19/91)
In article <1991Jan18.165311.18870@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > >>[lots of stuff deleted] > >>What I don't like about the Mac is that it is made by apple. I find the >>company policy of not selling ROMs anymore to be a vicious and malicious >>business practice. > > As a matter of interest, does Commodore sell their ROMs and custom >chips (Blitter, Copper) etc to anybody?? > You CAN buy replacement parts, and also you can buy them when they are changed, i.e. 2.0 and ECS. But we have no idea how Commodore would react if an emulator comes out. Currently there aren't any. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >"Dear Fascist Bully Boy, Give me some money, or else. Neil. P.S. May >the seed of your loins be fruitful in the womb of your woman..." -- Ethan "What a waste it is to lose one's mind, or not to have a mind... How true that is." -- Dan Quayle, of course. Our beloved Vice President. It's just too easy!
yorkw@stable.ecn.purdue.edu (Willis F York) (01/19/91)
> You CAN buy replacement parts, and also you can buy them >when they are changed, i.e. 2.0 and ECS. But we have no idea how >Commodore would react if an emulator comes out. Currently there >aren't any. Hmmm A Amiga Clone... Isin't some English company doing that with the 2000? Putting in another drive, memory,ect, and calling it a 1500? And there's the A1500 case they ya put ya 500 in, makes it look like a "1000'ish" thing. I don't know if i'd buy an Amiga clone.. How much cheaper could they get amigas? (I'd buy a Portable Amiga Clone tho... Because CBM don't have one!) . -- yorkw@ecn.purdue.edu Willis F York ---------------------------------------------- Macintosh... Proof that a Person can use a Computer all day and still not know ANYTHING about computers.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (01/19/91)
In article <yorkw.664223561@stable.ecn.purdue.edu> yorkw@stable.ecn.purdue.edu (Willis F York) writes: >> You CAN buy replacement parts, and also you can buy them >>when they are changed, i.e. 2.0 and ECS. But we have no idea how >>Commodore would react if an emulator comes out. Currently there >>aren't any. > >Hmmm A Amiga Clone... Isin't some English company doing that with the 2000? >Putting in another drive, memory,ect, and calling it a 1500? > >And there's the A1500 case they ya put ya 500 in, makes it look like >a "1000'ish" thing. > Well, you still have to buy an Amiga from COMMODORE to get that A1500. It is merely a new case. >-- >yorkw@ecn.purdue.edu Willis F York >---------------------------------------------- >Macintosh... Proof that a Person can use a Computer all day and still >not know ANYTHING about computers. -- Ethan "What a waste it is to lose one's mind, or not to have a mind... How true that is." -- Dan Quayle, of course. Our beloved Vice President. It's just too easy!
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/19/91)
In article <1991Jan18.055614.13889@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: In article <MWM.91Jan14113155@raven.relay.pa.dec.com> mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >[Still trying to push this back to comp.sys.amiga.misc - mwm] > >In article <1991Jan11.081137.17529@zorch.SF-Bay.ORG> mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > There must be 2 kinds of tasks possible in a "true" multitasking system. > One kind of task is the kind that Amiga and Multifinder support, multiple > applications. The second is one that multifinder does not support which > is a task that is part of an application and is spawned while the > application runs and terminates sometime before (or right when) the > application quits. > >The only thing interesting you might be talking about is lightweight >processes. The only reason those are interesting is because they're >cheaper than normal processes. In any case, they have nothing to do >with the topic at hand. It has everything to do with the discussion at hand. Without what you call lightweight processes, you have something less than what you have with them. Without lightweight processes, you DON'T HAVE true multitasking. Boy, are the Unix people going to be surprised when you try and tell them they don't have "true" multitasking - whereas the Amiga, which isn't even a "real" computer, does. True multitasking is what the posting was about that this response was made to. Yes, but you obviously have no idea what is meant by that phrase. Lightweight processes allow you to have a second task that writes graphics to the screen while another manipulates pulldown menus. Lightweight processes allow a hard disk backup program to read from hard disk, compress, and write to floppy (that is 1 application plus 2 lightweight processes) in the most efficient manner possible. It allows applications to take advantage of the multitasking environment. Neither of these require lightweight processes. The latter one doesn't require multitasking _at all_ - you can do it with co-routines and asynch IO. The latter requires multitasking by definition (you required two processes), but can be done with cooperative multitasking - which means it could be done with co-routines inside one task. Call me an anal retentive amiga user because I am one. Actually, I don't think you're anal retentive; that usually implies a obsession with getting things exactly right, which you don't show. This thread is not just a bunch of Amiga guys having an intelligent discussion about various kinds of multitasking. It is Amiga guys explaining the difference between TRUE multitasking, which the Amiga has, and a switcher (albeit a glorious one) which the Mac has. No matter what we (Amiga) say, they (Mac) don't wanna believe that what they have is any less than what we have. You still don't know what you're talking about - but this time it's because you jumped into the middle of a conversation without trying to understand it. This conversation is a few Amiga owners trying to improve the image of _all_ amiga owners by getting them to drop the inflammatory phrase "true multitasking" in favor of the technically more accurate phrase with prior usage - "preemptive multitasking". Iny our specific case, I'd recommend the practice of understanding what you're going to talk about before you start. <mike -- How many times do you have to fall Mike Meyer While people stand there gawking? mwm@pa.dec.com How many times do you have to fall decwrl!mwm Before you end up walking?
new@ee.udel.edu (Darren New) (01/19/91)
I tried to mail this, but it bounced... In article <MWM.91Jan18153532@raven.relay.pa.dec.com> you write: >Neither of these require lightweight processes. The latter one doesn't >require multitasking _at all_ - you can do it with co-routines and >asynch IO. The latter requires multitasking by definition (you >required two processes), but can be done with cooperative multitasking >- which means it could be done with co-routines inside one task. Please tell me the difference between coroutines and lightweight processes. I always thought that lightweight processes were two 'tasks' (i.e., independant program counters) sharing the same address space. I.e., the Amiga is one big process with lots of lightweight processes inside. I though coroutines were a specific mechanism for specifying creation and termination of lightweight processes. You make it sound as if coroutines are somehow simpler than lightweight processes, or that lightweight processes can do things that coroutines cannot. I'm interested in what you think the differences are. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
djohnson@beowulf.ucsd.edu (Darin Johnson) (01/19/91)
In article <42149@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >Please tell me the difference between coroutines and lightweight >processes. I always thought that lightweight processes were two >'tasks' (i.e., independant program counters) sharing the same address >space. Lightweight processes (LWP) and co-routines (CR) have much in common, and some people blur the definition. Usually however, LWP's have the ability to context switch anywhere, like any process. CR's need only change context at IO, semaphores, and other special calls. CR's are a language construct, whereas LWP's are an OS construct. CR's require much less OS and machine support, but require more compiler support (co-routines share the same stack, global vars, etc). Actually, to avoid confusion, compiler support is not needed. CR's can be done in assembler without much fuss - device drivers often do this (usually when LWP's are unavailable). -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
new@ee.udel.edu (Darren New) (01/19/91)
In article <15750@sdcc6.ucsd.edu> djohnson@beowulf.ucsd.edu (Darin Johnson) writes: >In article <42149@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >>Please tell me the difference between coroutines and lightweight >>processes. >Lightweight processes (LWP) and co-routines (CR) have much in common, >and some people blur the definition. Usually however, LWP's have the >ability to context switch anywhere, like any process. CR's need only >change context at IO, semaphores, and other special calls. So you mean that the Amiga is full of LWPs and the Mac is full of CRs? :-) Correct me if I'm wrong, but I think you are saying that CRs are non-preemptive. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (01/22/91)
>>>>> In article <15750@sdcc6.ucsd.edu>, djohnson@beowulf.ucsd.edu (Darin Johnson) writes:
Darin> [...]. CR's require much less OS and machine support, but
Darin> require more compiler support (co-routines share the same
Darin> stack, global vars, etc).
Darin> Actually, to avoid confusion, compiler support is not needed.
Darin> CR's can be done in assembler without much fuss - device
Darin> drivers often do this (usually when LWP's are unavailable).
The uSystem (micro-system) project here at UW provides both
pre-emptive lightweight processes and coroutines under Unix without
any compiler support. Straight gcc is used. Normal BSD system calls
are used. (Provides support for multi-processor Unix machines as
well).
For more information, send mail to "usystem@maytag.uwaterloo.ca".
Hamish.
--
--------------------------------------------------------------------
himacdon@maytag.uwaterloo.ca watmath!maytag!himacdonm0154@tnc.UUCP (GUY GARNETT) (01/23/91)
This is my understanding of the "threads" or "lightweight processes" issue; feel free to correct me if I am not up to date on the terminology. "threads", or "lightweight processes" are separate execution traces which share the address spaces with one or more other processes, regardless of the other processes weight. They were designed to allow many of the simpler multitasking jobs (like re-drawing the screen or recalculating the spreadsheet) to be done with lower overhead. They are implemented in OS/2 and perhaps the Mach kernal. "coroutines" are the individual processes in a cooperatinve multitasking environment. The main program coordinates the activity of multiple subroutines, so that the system multitasks effectively. Unlike preemptive multitasking, cooperatinve multitasking places a demand on the programmer to ensure that the system operates efficently. One improperly programmed routine can cause the whole system to fall apart without really intending to. As I understand it, the Amiga does not have "threads" or "lightweight processes". The Amiga does make a distinction between "processes" and "tasks". A process could be described as a task that is known to AmigaDOS (Amiga EXEC handles multitasking, at a level below AmigaDOS). Processes have a current directory, standard input and output streams, and some other things which tasks do not. One time I explained this to a Unix programmer, and his initial response was "Oh! Tasks are a kind of daemon, then? ... (Well sort of). Although all of the tasks and processes on the Amiga share an address space, it is not intended that there be multiple execution traces through the same code and data (with the well-defined exception of certian operating system code). You *CAN* do it, but you do not get the same benefits that threads get - the operating system overhead is the same, and writing code to work this way adds its own overhead. Wildstar
new@ee.udel.edu (Darren New) (01/24/91)
In article <672@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >As I understand it, the Amiga does not have "threads" or "lightweight >processes". The Amiga does make a distinction between "processes" and >"tasks". A process could be described as a task that is known to >AmigaDOS (Amiga EXEC handles multitasking, at a level below AmigaDOS). Not really. AmigaDOS does indeed have lightweight processes, which are called "tasks". An AmigaDOS "process" is a task with an easily- locatable communication buffer for use by certain system libraries (primarily the file system). However, tasks can and do perform I/O via message passing. The filesystems simply require that the I/O be done to a certain location. >Processes have a current directory, standard input and output streams, >and some other things which tasks do not. Yes. AmigaDOS "processes" are supersets of tasks, but the differences have nothing to do with addressing or scheduling. >Although all of the tasks and processes on the Amiga share an address >space, it is not intended that there be multiple execution traces >through the same code and data (with the well-defined exception of >certian operating system code). There can be. What do you mean by "the same code"? The same executable image in memory? Happens all the time (with "resident" programs), i.e., shared-code in UNIX-speak. Many programs (esp games and telecom programs) have multiple tasks using the same non-shared executable. >You *CAN* do it, but you do not get >the same benefits that threads get - the operating system overhead is >the same, and writing code to work this way adds its own overhead. It is exactly the same as threads. Tell me what a thread gives you that an AmigaDOS task does not? Or vica versa. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
m0154@tnc.UUCP (GUY GARNETT) (01/25/91)
In article <42598@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >In article <672@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >>As I understand it, the Amiga does not have "threads" or "lightweight >>processes". The Amiga does make a distinction between "processes" and >>"tasks". A process could be described as a task that is known to >>AmigaDOS (Amiga EXEC handles multitasking, at a level below AmigaDOS). > >Not really. AmigaDOS does indeed have lightweight processes, which >are called "tasks". An AmigaDOS "process" is a task with an easily- >locatable communication buffer for use by certain system libraries >(primarily the file system). However, tasks can and do perform I/O >via message passing. The filesystems simply require that the I/O >be done to a certain location. > Tasks are not lightweight Processes; tasks and processes are the same to Exec. The distinction is at the AmigaDOS level; as I said in my first message. Tasks and Processes can both do I/O through DOS; processes have the necessary DOS structures built-in, tasks must do some setting-up first. Tasks and Processes can both use the file system; processes simply have it pre-defined for them (I never said differently, please read my original message). > >>Processes have a current directory, standard input and output streams, >>and some other things which tasks do not. > >Yes. AmigaDOS "processes" are supersets of tasks, but the differences >have nothing to do with addressing or scheduling. > Right. That's what I said. From the point of view of the threads vs no-threads debate, Amiga tasks and processes are the same. They are, of course, not the same to AmigaDOS. > >>Although all of the tasks and processes on the Amiga share an address >>space, it is not intended that there be multiple execution traces >>through the same code and data (with the well-defined exception of >>certian operating system code). > >There can be. What do you mean by "the same code"? The same executable >image in memory? Happens all the time (with "resident" programs), i.e., >shared-code in UNIX-speak. Many programs (esp games and telecom programs) >have multiple tasks using the same non-shared executable. > >>You *CAN* do it, but you do not get >>the same benefits that threads get - the operating system overhead is >>the same, and writing code to work this way adds its own overhead. > Yes, I am talking about the same image in memory. The well defined exception I am talking about is when pure code is made resident. This is usually used for system level code, cli commands, and the like; I don't think it is indended that applications programs be made resident (can you imagine re-coding wordperfect so that it is pure, and then making it resident? Yes, it could be done, but it soulds like a lot of work for little benefit; better to modify it so that it can handle more documents at once without bogging down). Multiple programs using the same executable, loaded at different locations in memory (one for each invocation of the program) is a different beastie; most Amiga software should be coded so that this is possible. > >It is exactly the same as threads. Tell me what a thread gives you >that an AmigaDOS task does not? Or vica versa. -- Darren > >-- >--- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- >----- Network Protocols, Graphics, Programming Languages, > Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- > =+=+=+ Let GROPE be an N-tuple where ... +=+=+= The distinction made in other operating systems (OS/2 and a few others) is that multiple threads execute as one task, and the operating system manages multiple tasks. The task switch on these operating systems is quite involved and time-consuming; and every task has a separate address space. Threads within a task share the same address space (that of the task), and switching between threads within a task is relatively fast and efficient. While the amiga does not have threads, Exec has some of the features that threads are supposed to bring to other operating systems (specifically, lower operating system overhead and faster task switches for better real-time response). Because of the design of the Amiga hardware, the amiaga also has all of its tasks sharing the same address space; but amiga programs are not supposed to reference memory that they have not received control of (through memory allocation or message passing). In short, threads are implemented in other operating systems to improve the efficency of the OS with regard to handling multiple, closely-coupled tasks, all of which are working on parts of the same problem. The Amiga does not have threads, and doesen't need them, because its multitasking and message passing systems are already highly efficient. What other operating systems need a special facility for is simple one more application of the Amiga's multitasking operating system. And it has been for years. Wildstar
daveh@cbmvax.commodore.com (Dave Haynie) (01/25/91)
In article <1991Jan18.165311.18870@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >mykes@zorch.SF-Bay.ORG (Mike Schwartz) writes: > As a matter of interest, does Commodore sell their ROMs and custom >chips (Blitter, Copper) etc to anybody?? They have an OEM program which sells things like A500 motherboards. These wind up in strange places, like arcade video machines and similar devices. And of course ROMs are sold through normal dealer channels. The custom chips are available as upgrades, but not priced in such a way that you'd want to base a commercially available system (eg, AmigaClone) on them. With few exceptions, Commodore systems have traditionally been tied to hardware enough to make clones difficult, at least within a generation (an Amiga can kind of emulate a C64, but it would be difficult to build any C64 compatible for less than a real C64 and therefore compete). Apple has been virtually hardware independent (as long as you have a 680x0 based CPU or a software engine that does a reasonably fast 680x0 emulation), so they naturally have to keep tight controls on their ROMs, if they wish to prevent Mac clones. A SoftAmiga running on a Mac or other system would actually be a good advertisement for real Amigas, since the blitter, copper, and other hardware would be difficult to emulate in realtime in software. So you would probably find only rather generic programs ran well, assuming Intuition and Graphics were rewritten to be blitterless. >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
peter@sugar.hackercorp.com (Peter da Silva) (01/28/91)
In article <42154@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: > So you mean that the Amiga is full of LWPs and the Mac is full of CRs? :-) No, both are full of *processes*. The difference between LWPs and CRs is that CRs specify the routine to continue on the context switch. Cooperative Multitasking (CM) is an implementation of LWPs using a scheduler to transparently select the next coroutine to execute. I posted an implementation of CM using CRs in C to one of the comp.unix groups a year or so ago. I used setjmp/longjmp to do the co-call with some unspecified magic juju to set up the stack. > Correct me if I'm wrong, but I think you are saying that CRs are > non-preemptive. -- Darren CR are non-scheduled. To confuse things further, the traditional UNIX kernel is implemented as a set of coroutines that call the scheduler as a subroutine. The UNIX kernel is non-preemptive, but UNIX user processes are preemptable. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
new@ee.udel.edu (Darren New) (01/29/91)
In article <678@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >In article <42598@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >>In article <672@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >>>As I understand it, the Amiga does not have "threads" or "lightweight >>>processes". >>Not really. AmigaDOS does indeed have lightweight processes, which >>are called "tasks". >Tasks are not lightweight Processes; tasks and processes are the same >to Exec. That's what I said. "Tasks" on the Amiga are what computer scientists call "lightweight processes" or "threads". Since they share the address space, all Amiga "tasks" are all threads of the same process. (Note quotes for Amiga terminology.) >Yes, I am talking about the same image in memory. The well defined >exception I am talking about is when pure code is made resident. How about backup programs spawning compression routines, terminal programs having a sender routine and a receiver routine, multiple programs calling the same library at the same time, etc? I think you recognise much less of the code sharing than is really there. >(can you imagine re-coding wordperfect so that it is pure, >and then making it resident? Yes, it could be done, but it soulds >like a lot of work for little benefit; Lattice (and probably Manx) both can do this with a compiler switch. I usually do it, because it is no extra work. >>It is exactly the same as threads. Tell me what a thread gives you >>that an AmigaDOS task does not? Or vica versa. -- Darren >The distinction made in other operating systems (OS/2 and a few >others) is that multiple threads execute as one task, and the >operating system manages multiple tasks. The task switch on these >operating systems is quite involved and time-consuming; and every task >has a separate address space. Threads within a task share the same >address space (that of the task), and switching between threads within >a task is relatively fast and efficient. Hence, what OS/2 calls a thread, Amiga exec calls a "task". All "tasks" within the Amiga share the same address space, so they are all part of the same process. Thence, the Amiga is full of LWPs, (or "tasks", or threads,) all of which are part of the same process. >but amiga programs are not supposed to reference memory >that they have not received control of (through memory allocation or >message passing). And "threads" in most multiprogramming systems are not supposed to access shared memory they have not received control of. >The Amiga does not have threads, and doesen't need them, >because its multitasking and message passing systems are already >highly efficient. What other operating systems need a special >facility for is simpl[y] one more application of the Amiga's >multitasking operating system. And it has been for years. I think we are in violent agreement here. There was just a confusion of terminology which I believe I have cleared up. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
new@ee.udel.edu (Darren New) (01/29/91)
In article <1991Jan27.100824.6629@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >When a 1 line C program can bring down the system...... But you can do that on an IBM or a Mac also. Commodore just made the mistake of making a system crash amusing enough to talk about it. -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
davewt@NCoast.ORG (David Wright) (01/29/91)
In article <1991Jan27.100824.6629@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >I don't know about calling it a feature! I am sick of the >lack of memory protection. I would definitely endure slightly slower >performance and the need for some major software re-writes >for it. Then you are in the minority of Amiga owners. Most would prefer it, if it didn't hamper current programs, and I don't know anyone who is against it if future programs could be written which supported it, as long as current programs could be run as well. Personally, I am GLAD the Amiga is not Unix, and does not try to be. If I wanted Unix I would use it (3000UX). Unix is like a big old-fashioned Cadilac. It includes things for every user that many users don't want/need, and protects everyone behind battleship strength security and impact resistance. The Amiga is like a compact sports car. When you hit a bump, you know it. But if it is driven by a knowledgeable driver, the results are far better than anything a Caddy could ever do. And if the software is written correctly, the user will never even know that there is no memory protection. If you have used 2.0 you will have seen (if you have been able to guru your machine, I haven't been able to in about a year) the "Task Held" requester, which is about as close to memory protection as many people will ever need. And if you are a developer (the only ones who would be writing any new software) you are a fool to develop and run critical software on the same machine, in any OS (I work in Unix 3.2.2 all day, and I would never think of running production code on the same machine a develop on). > >When a 1 line C program can bring down the system...... > Gee, I guess this also includes Unix, Xenix, MS-DOS, and the Mac too, right? Dave
m0154@tnc.UUCP (GUY GARNETT) (01/31/91)
>>When a 1 line C program can bring down the system...... > Gee, I guess this also includes Unix, Xenix, MS-DOS, and the >Mac too, right? How about a 2-line FORTRAN program crashing an IBM 3083? I've done it; every operating system has its weakness, you simply have to try harder with some than with others. If you take some care and pride in your work, you can write decent, maintainable and reliable code on the Amiga, or on any other system, for that matter. If you don't learn (or don't bother to learn) the difference between right and wrong programming practices, then you will have a difficult time writing good, relaible, and efficent code on any machine. In the very beginning (now I'm talking about v1.0 and v1.1) the Amiga was a hard machine to program for. The learning curve was steep, there was likely to be nobody around who knew the answers to your questions, and the documentation was spotty, or incomplete. Now, its a different ballgame. I would compare the Amiga programming environment quite favorablly to those available on other personal computers with GUI's. Yes, the learning curve is still steep, but no worse (and in many cases better than) other GUI systems. There is good documentation, reliable tools, and expert advice available. No, you can't program it the same way you program on an IBM PC or a mainframe, but then again, the Amiga is not an IBM PC or a mainframe. For which I am very glad. Wildstar
burley@geech.ai.mit.edu (Craig Burley) (01/31/91)
In article <1991Jan28.220234.29712@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: In article <1991Jan27.100824.6629@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >I don't know about calling it a feature! I am sick of the >lack of memory protection. I would definitely endure slightly slower >performance and the need for some major software re-writes >for it. Personally, I am GLAD the Amiga is not Unix, and does not try to be. If I wanted Unix I would use it (3000UX). Unix is like a big old-fashioned Cadilac. It includes things for every user that many users don't want/need, and protects everyone behind battleship strength security and impact resistance. The Amiga is like a compact sports car. When you hit a bump, you know it. But if it is driven by a knowledgeable driver, the results are far better than anything a Caddy could ever do. Uh...no. UNIX ain't no cadillac. Most implementations I know of do provide memory protection because they provide virtual memory, but I don't think either one is required by any standard UNIX. Cadillac OS? Try Multics, or maybe VAX/VMS. Under UNIX, you get nothing but a bunch of little tools. You're supposed to hook them up together however you need to do the job. There's no "undelete", for example -- but you can implement it if you want, and fairly easily. There's no command line processor -- but one or more "shells" available, which means you can write your own. AmigaOS is almost certainly head and shoulders above any other OS when running on Amiga computers, especially because of the specialized hardware they use, also because of their target audience. This isn't surprising and doesn't really say much -- but I said it in case anyone thought I disagreed with "the results are far better than anything a Caddy could ever do". If I had to travel through a forest fast, I'd prefer a motorcycle to a Caddy, too. My impression of UNIX and AmigaOS is that AmigaOS has lots of the "good" features of UNIX -- flexibility, the ability to remain fairly stripped-down, et cetera -- while forgoing multi-user capability, and adding more modern built-in facilities like graphics management, perhaps(?) a more full- featured file system, and so on. But comparing UNIX and AmigaOS is much less useful than comparing AmigaOS to Mac OS and/or MS-DOS and/or VMS &c, for one simple reason: unlike the others, UNIX is a portable operating system. No matter what faults it has, this is the one big reason it is becoming so popular. From lowly 286 machines to Crays, UNIX can reside. In this sense, AmigaOS and MacOS are cadillacs and UNIX the motorcycle -- it is much more flexible in this field of endeavor (portability) than are they, and also much more limited, because it can't standardize around things that aren't common among many varieties of machines. If I knew for sure I was going to be working on only one basic machine/architecture for a long, long time, I'd do my best to avoid UNIX. Because I don't, I must embrace it. Ooomph. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (01/31/91)
In article <694@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >>When a 1 line C program can bring down the system...... > Gee, I guess this also includes Unix, Xenix, MS-DOS, and the >Mac too, right? How about a 2-line FORTRAN program crashing an IBM 3083? I've done it; every operating system has its weakness, you simply have to try harder with some than with others. The difference is that on Unix & the IBM, this is considered a bug in the OS, and you have some hope of getting people to fix it. On the Amiga/Mac/MS-DOS, it's a bug in the application (even if the application meant to do it), and there's no way anyone is going to fix it. That's one reasonable definition of "real" computers - that the system crashing is considered to a system problem, and not an application problem. <mike -- He was your reason for living Mike Meyer So you once said mwm@pa.dec.com Now your reason for living decwrl!mwm Has left you half dead
ckp@grebyn.com (Checkpoint Technologies) (02/02/91)
>That's one reasonable definition of "real" computers - that the system >crashing is considered to a system problem, and not an application >problem. (Note that I'm trying to direct this into .advocacy...) I think it's also a reasonable definition of "personal" computers that the "system" affects one person only. In such a case, it's difficult to discern the difference, to the person, between a "system" failure and an "application" failure. Both affect the person just as much. The biggest difference is whether the application is relanched or the system rebooted. A multi-tasking personal system is slightly different, because the person may be engaged in several applications, but the number of persons affected by a crash is still one. In multi-user computers, there is a "system" authority and applications are served out to multiple users. In this case it is unforgivable that the actions of one user affect another, therefore the "system" takes great pains to protect itself, and therefore other users. It is from this environment that Unix was born. My point? If you want protection, if you want a "real" computer, get Unix. You have no other choice, because you can be sure that AmigaDOS will never have the protection you're asking for, all arguments aside. Asking for it is pointless. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
gjc@lsw.UUCP (Greg) (02/04/91)
In article <MWM.91Jan30173903@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > That's one reasonable definition of "real" computers - that the system > crashing is considered to a system problem, and not an application > problem. > > <mike Excuse me?? How can a programmer, who is human, possibly account for all possible contingencies??? Does this mean that every time an application crashes your Amiga/Mac that the system designers are at fault just because some funky programmer who doesn't know what he's doing wrote some strange out-of-this world program?? Or better yet!! are Are you trying to say that the Amiga is not a "real" computer??? Inquiring minds want to know!! :) Gregory John Casamento (The Borgster!!)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/05/91)
In article <186@lsw.UUCP> gjc@lsw.UUCP (Greg) writes: In article <MWM.91Jan30173903@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > That's one reasonable definition of "real" computers - that the system > crashing is considered to a system problem, and not an application > problem. > > <mike Excuse me?? How can a programmer, who is human, possibly account for all possible contingencies??? They can't - at least not for anything nontrivial. Does this mean that every time an application crashes your Amiga/Mac that the system designers are at fault just because some funky programmer who doesn't know what he's doing wrote some strange out-of-this world program?? The definition I just stated implies that if the answer to that question isn't "yes", then you're not using a real computer. Or better yet!! are Are you trying to say that the Amiga is not a "real" computer??? No - I'm simply stating a definition for the term "real computer". Whether any particular machine meets the definition is immaterial. <mike -- My feet are set for dancing, Mike Meyer Won't you turn your music on. mwm@pa.dec.com My heart is like a loaded gun, decwrl!mwm Won't you let the water run.
daveh@cbmvax.commodore.com (Dave Haynie) (02/07/91)
In article <186@lsw.UUCP> gjc@lsw.UUCP (Greg) writes: >In article <MWM.91Jan30173903@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >> That's one reasonable definition of "real" computers - that the system >> crashing is considered to a system problem, and not an application >> problem. >Excuse me?? How can a programmer, who is human, possibly account for >all possible contingencies??? What Mike is alluding to here is that an operating system, with the proper hardware support, can be written to trap and deal with programming errors. Your OS needs two basic features -- a per-task MMU context, and resource tracking, to do this correctly. Basically what happens is this: when a task context changes, a new MMU table is referenced a the user level. This table grants read/write permission to the memory resources owned by the new task, possibly read-only permission to system global resources, and makes any other memory access an error. Along with this, the system software tracks every memory or allocation made by the task. Should the task happen to access something it doesn't own, the MMU will cause an exception, calling up an OS control program that knows how to free up whatever the errant task has allocated and then eliminate the task itself. In the AmigaOS, resources are mediated by the OS, but it's up to each application to free them, and there's no way for the OS to know just what any application has allocated. Additionally, the OS doesn't manage a per-task MMU context (strangely enough, the majority of Amigas don't have MMUs), so hardware supported error trapping at present is a developer tool, not part of the general OS. In most cases, it's much better for the OS to handle resource tracking, just as it handles resource allocation, graphics, filesystem, etc. >Does this mean that every time an application crashes your Amiga/Mac >that the system designers are at fault just because some funky programmer >who doesn't know what he's doing wrote some strange out-of-this world >program?? What this says is that, had the system been designed differently, bad programming would not crash the system, just the application. You would also need an A2500/20 at the least to run the system. Ideally, the fact that the OS doesn't afford this protection will, in the long run, provide us with better quality applications. Since it's far more important to avoid bugs on an Amiga application, you tend to see these applications written more carefully than the typical protected-OS application. Because the very nature of the AmigaOS makes a great number of bugs obvious, whether in a crash or trapped by a development tool. UNIX, for example, can very easily hide a large number of different bugs, many of which result from the sloppy programming style popular on these systems (some of the GNU code is a good example); ints instead of pointers, macros where you should have a typedef, the assumption of near infinite memory availability, the list goes on. Obviously, a fatal bug in a UNIX program is less annoying than a similar one on an Amiga system. But that's kind of like saying that smashing up your car near a hospital is less annyoing than doing it out on a deserted road in the middle of the Pine Barrens. Proper methodology, whether driving or programming, avoiding the catastrophe in the first place, is best of all. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
gjc@lsw.UUCP (Greg) (02/10/91)
In article <MWM.91Feb4105909@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > No - I'm simply stating a definition for the term "real computer". > Whether any particular machine meets the definition is immaterial. > On that note, all I am trying to say is that operating systems are written by people, people are fallable and therefore so are operating systems. By your definition quite a few of todays computers would not be real computers. For example... by using direct addressing I could erase all the memory locations in a Prime minicomputer/mainframe, or by moving a zero to a particular register (using a non-privileged account) you can crash a VAX/VMS minicomputer. And the list would go on and on... It would be very nice if a microcomputer operating system could accomplish this, but it would have to be *very* robust and have a high price. I am not refutinge the fact that there may be some OSs out there which are totally bulletproof, but I have yet to see one. BTW, you might consider saying "real operating system" since what you referred to in your first note was concerning the OS not the computer. Contrary to what you might think the OS has very little to do with the computer it's running on. A primary example of this would be UNIX which currently runs on DEC, Apple Mac, Amiga,some 386s, some 286s, etc. (Also BTW, UNIX is not bulletproof *by far* so I guess it's not a "real" operating system!)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/12/91)
In article <187@lsw.UUCP> gjc@lsw.UUCP (Greg) writes: In article <MWM.91Feb4105909@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > No - I'm simply stating a definition for the term "real computer". > Whether any particular machine meets the definition is immaterial. > On that note, all I am trying to say is that operating systems are written by people, people are fallable and therefore so are operating systems. Yes, they are. I'm not trying to say that the definition implies that no application can crash the system; merely that when that happens, it's considered a bug in the system, not the application. By your definition quite a few of todays computers would not be real computers. For example... by using direct addressing I could erase all the memory locations in a Prime minicomputer/mainframe, or by moving a zero to a particular register (using a non-privileged account) you can crash a VAX/VMS minicomputer. It's been a long time since I looked at a PR1ME, but given what I saw then, I wouldn't be surprised if what you describe is considered a feature. Which would indeed make a PR1ME not meet that definition of real computer - which matched the conclusions of the time I looked at it. We bought a VMS system instead. On the other hand, our VAX/VMS people assure me that the bug you describe is a bug in the OS, and fixed on our systems. And the list would go on and on... I dunno - most of the hardware I've worked on don't provide features that allow non-privileged users to crash the system. Most of them had _bugs_ that let that happen. The systems people were trying to fix them. If the systems people had been trying to convince me that the applications program was at fault, then I would have said they didn't have a real computer. It would be very nice if a microcomputer operating system could accomplish this, but it would have to be *very* robust and have a high price. That statement was true 10 years ago, and probably true five years ago. I don't believe it's true now. An A3000UX would qualify (I know of no features in Unix that allow applications to crash the system). I am not refutinge the fact that there may be some OSs out there which are totally bulletproof, but I have yet to see one. I'm not saying that a computer has to have a bulletproof OS to meet that definition; I'm saying that the OS design has to have the _goal_ of being bulletproof to meet that definition. BTW, you might consider saying "real operating system" since what you referred to in your first note was concerning the OS not the computer. Look at the topic. Think about the history of the discussion. Contrary to what you might think the OS has very little to do with the computer it's running on. A primary example of this would be UNIX which currently runs on DEC, Apple Mac, Amiga,some 386s, some 286s, etc. Contrary to what you might think, SOME os's are very much tied to the computer they're on. A primary example of this would be AmigaDOS, which has to have a 680x0 based processor, and a nice set of custom silicon as well. Also, the OS expects to see some set of capabilities from the hardware, and won't run without that. But yeah, you're right - hardware can run multiple OSs, and some of them have being bulletproof as a goal; others don't. It can be argued (and has been previously in this thread) that a Mac running AUX is in some way different from a Mac running finder, as the users see radically different behavior. <mike -- [Our regularly scheduled .signature preempted.] Mike Meyer The Amiga 1000: Let's build _the_ hackers machine. mwm@pa.dec.com The Amiga 500: Let's build one as cheaply as possible! decwrl!mwm The Amiga 2000: Let's build one inside an IBM PC!
UH2@psuvm.psu.edu (Lee Sailer) (02/13/91)
...and of course, even bug free (I mean really, totally, absolutely bug free) systems can crash. Making a system crash proof and being bug free are two different concepts. Making a system crash proof sometimes requires considerable overhead, such as always checking processes to see if a deadlock has occurred. If the *designers* of the system decide that deadlock is so rare that the cost of detecting or avoiding it is not worth it, then they won't put those features in. (No, we don't use this system for air traffic control 8-)
gjc@lsw.UUCP (Greg Casamento) (02/17/91)
In article <MWM.91Feb11115014@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > I'm not saying that a computer has to have a bulletproof OS to meet > that definition; I'm saying that the OS design has to have the _goal_ > of being bulletproof to meet that definition. I see your reasoning now...and I agree. When I first read the note I thought that you were saying that any computer which could be crashed by an application is not a real computer, but I obviosly mis- understood. > Contrary to what you might think, SOME os's are very much tied to the > computer they're on. A primary example of this would be AmigaDOS, > which has to have a 680x0 based processor, and a nice set of custom > silicon as well. Also, the OS expects to see some set of capabilities > from the hardware, and won't run without that. This is true... But, certain OS's can be ported to other platforms. > But yeah, you're right - hardware can run multiple OSs, and some of > them have being bulletproof as a goal; others don't. It can be argued > (and has been previously in this thread) that a Mac running AUX is in > some way different from a Mac running finder, as the users see > radically different behavior. > Any decent operating system/hardware design should be capable of handling application problems to an extent, but thier integrity cannot be guaranteed. Just so long as they have the goal of being bulletproof in mind, that's good enough for me. But, you never know about some OS's, after all nobody's perfect! > <mike -- **************************************************************************** Gregory John Casamento (The Borgster!!!) Standard Disclaimer: All standard disclaimers apply! :) ****************************************************************************