daveh@cbmvax.UUCP (Dave Haynie) (03/21/89)
in article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: > In-reply-to: schow@bnr-public.uucp's message of 19 Mar 89 10:26:57 GMT > > In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: >>I am very happy with Amiga. Why should I trade in a fast Amiga >>for a slow Unix? > > Unix is an operating system. The Amiga is a computer. The Amiga can > run Unix. (The 2500UX already does.) Your assumption that Unix is > inherently slow is patently absurd. Untrue. The Amiga Exec is just plain more efficient than the AT&T UNIX Kernel. Task swaps under exec are extremely light weight when compared to UNIX swaps. FFS runs around 3x the speed of the standard System V file system, on the same A2500 hardware, without swapping in the way (at least that was the last rough figure -- don't know if Steve's latest have recently been compared with Mike/Johann's latest, but I wouldn't expect too much change). Despite what the UNIX-or-death folks say, UNIX isn't perfect. It does lots of things right. Some things OK. Let's not even talk about added device drivers... > The Amiga can't even do that. It doesn't have an MMU. To quote the well known UNIX wizard Deven Thomas Corzine, "The 2500UX already does." So do all other 2500s. > If you ran Unix on the Amiga without paging (which isn't possible) or > swapping (which is quite possible, but only really feasible with a HD) > you will get similar speeds to programs running on the Amiga under > AmigaDOS. You CAN'T run UNIX without paging, that's part of the task swap overhead in UNIX, and one of the reasons it goes slower (and, of course, this slowdown also makes fork() possible, so it's not a clear loss. But what is?). I'm not at all claiming that it goes considerably slower, just slower. Also, once you start swapping, obviously, you will go slower. It doesn't take that many programs running to start swapping. Care to guess how may programs I have running on my Amiga system here (if you guessed 35, you'd win the cupie doll). I'm using less than 1.7 megabytes of RAM. Shared libraries sure make a difference. >> Consider the problems of expanding wildcard in the shell: >> - increditably long lines are passed around. > So? Either the shell builds an incredibly long line and pulls the > parameters from it to pass to the program, or you pass the program the > command line directly (as the CLI does) and the program builds the > same incredibly long line. Big lot of difference it makes. I thought you said you understood pipes? It makes a big difference. > Deven -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (03/22/89)
In article <6352@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: >> Your assumption that Unix is inherently slow is patently absurd. > >Untrue. The Amiga Exec is just plain more efficient than the AT&T UNIX >Kernel. Task swaps under exec are extremely light weight when compared to >UNIX swaps. FFS runs around 3x the speed of the standard System V file >system, on the same A2500 hardware, without swapping in the way (at least >that was the last rough figure -- don't know if Steve's latest have >recently been compared with Mike/Johann's latest, but I wouldn't expect >too much change). Despite what the UNIX-or-death folks say, UNIX isn't >perfect. Absolutely true. An important thing to remember though, is that when you point to particular areas where OS "X" is better than OS "Y", you have to figure out how much those areas come into play in what you consider "normal use." Having a more effecient kernel only helps to the extent that the system spends time in the kernel. For example, if you run one CPU intensive program under AmigaDos, and an equivalent program under Unix, with nothing else running on either system, the ineficciencies in a Unix task switch won't matter and the difference between the systems will be negligible. However, In a situation with several remote users logged in to the the system via telnet, where there are a few context switches for every keystroke, Unix will start to feel the overhead in a context switch, and the effective CPU speed will start to drop. Ironically, AmigaDos is not appropriate for such use (multiple interactive users) and its advantages there are seldom seen, but those advantages do come into play with things like applications that run in multiple processes, etc. For another example, consider a program which is about half CPU bound and half file I/O bound. Running this program under AmigaDos (with FFS) and Unix will show the FFS to be much faster than the Unix filesytem. Run TEN of these programs simultaneously on each system and I'll bet Unix will be faster because of things like read-ahead and larger block sizes. >> If you ran Unix on the Amiga without paging (which isn't possible) or >> swapping (which is quite possible, but only really feasible with a HD) >> you will get similar speeds to programs running on the Amiga under >> AmigaDOS. > >You CAN'T run UNIX without paging, that's part of the task swap overhead >in UNIX, and one of the reasons it goes slower (and, of course, this >slowdown also makes fork() possible, so it's not a clear loss. Hmm? Deven and Dave both seem to be saying that Unix requires paging, which isn't true. Unix existed for 10 or 15 years before AT&T released a paging version. The early versions were "swapping" systems; only an entire process could be swapped to disk. Paging systems move small pages of memory to disk when they are not being used. On a paging or swapping system, it is trivial to configure the system not to use secondary storage for virtual memory (when all physical memory is in use, attempts to use more will result in out-of-memory errors). >I'm not at all claiming that it goes considerably slower, just >slower. I'm not convinced. Unix has things like demand-loading of executables and shared libraries with demand-copied shared data segments. These are things that only help in certain situations, but the same is true of things like fast context switches or file systems optimized for large sequential reads. All these factors will sometimes pile up toward one system, making it faster, and they will sometimes balance out. I'm not convinced that either Unix or AmigaOS is inherently "faster" overall. And of course, all the above factors are subject to change with new releases of Unix or AmigaDos; hopefully we'll someday see Unix with superfast context switches and real time response, and AmigaOS with MMU address translation, shared text&data segments, automatic stack allocation, read-ahead, and memory protection. > Also, once you start swapping, obviously, you will go slower. >It doesn't take that many programs running to start swapping. Care to >guess how may programs I have running on my Amiga system here (if you >guessed 35, you'd win the cupie doll). I'm using less than 1.7 >megabytes of RAM. Shared libraries sure make a difference. I don't see what that has to do with Unix vs. AmigaDos performance, aside from the additional memory usage of the Unix OS itself. To do equivalent things with equivalent performance under Unix and AmigaDos, the Unix system might need another megabyte of RAM to avoid paging. Then again, it might not, because there are situations where AmigaDos uses more memory than Unix (such as stack space, for example -- how many people always use a 10K or 20K stack size because of that occational program that needs it). Memory fragmentation is another example. And if you are only one megabyte short on physical memory, I claim that the paging is not noticable. It might have a slight effect on some I/O intensive operations, but will generally not effect the CPU time of programs because memory which is in use is not paged out. (Unless you are just plain using far more virtual memory than you have physical memory, and I think we all agree that once you do that, swap I/O is a fact of life). -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.commodore.com - The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
peter@sugar.hackercorp.com (Peter da Silva) (03/22/89)
In article <6359@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > Hmm? Deven and Dave both seem to be saying that Unix requires paging, > which isn't true. Back to the old confusion between virtual memory and mapped memory. UNIX absolutely requires mapped memory. > I'm not > convinced that either Unix or AmigaOS is inherently "faster" overall. You can add those things (big caches, for example) to AmigaOS. You would have to completely rewrite the UNIX kernel to get the advantages of AmigaOS in UNIX (which I think would be a really good idea, by the way... AmigaOS would make a great real-time kernel for UNIX). > Then again, it might not, because there are situations where AmigaDos > uses more memory than Unix (such as stack space, for example -- how > many people always use a 10K or 20K stack size because of that > occational program that needs it). UNIX does not require, nor does it always support, dynamically allocated stacks. For example, early 68000 UNIX didn't support dynamically allocated stack because even without an MMU the 68000 couldn't recover from the page fault (yes, page fault) when the user tried to write into non-allocated stack space. Some systems tried to use stack probes to get around this problem, but they were unreliable. Even today, many 80286 UNIXes don't support dynamic stacks. We have '286 programs that preallocate up to a full segment for the stack. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
deven@pawl.rpi.edu (Deven Corzine) (03/23/89)
In article <6352@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: >> In-reply-to: schow@bnr-public.uucp's message of 19 Mar 89 10:26:57 GMT >> >> In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: >>>I am very happy with Amiga. Why should I trade in a fast Amiga >>>for a slow Unix? > >> Unix is an operating system. The Amiga is a computer. The Amiga can >> run Unix. (The 2500UX already does.) Your assumption that Unix is >> inherently slow is patently absurd. >Untrue. The Amiga Exec is just plain more efficient than the AT&T UNIX >Kernel. Task swaps under exec are extremely light weight when compared to >UNIX swaps. FFS runs around 3x the speed of the standard System V file >system, on the same A2500 hardware, without swapping in the way (at least >that was the last rough figure -- don't know if Steve's latest have >recently been compared with Mike/Johann's latest, but I wouldn't expect >too much change). Despite what the UNIX-or-death folks say, UNIX isn't >perfect. It does lots of things right. Some things OK. Let's not even >talk about added device drivers... I never claimed Unix was perfect. I very much like Exec. I don't like AmigaDOS. There is a difference. Unix often uses static arrays for system structures (e.g. fd's) which is limiting. Exec is much more dynamic, using its doubly-linked lists instead. *That* is superior to Unix, by far. Besides, I don't mean specifically the AT&T Unix Kernel. Basically, what I mean when I say "the Amiga can run Unix" is that you could have a programming interface virtually identical to that provided in a more traditional Unix kernel, but you could implement it on top of Exec for efficiency, power and flexibility. The best of both worlds, as it were. I define Unix more by how it can be used than by the source code that defines it. The internal structure may differ, but given the same programmer interface (and hopefully followed with the same user interface) gives you the compatibility and portability that has long been a major cornerstone of Unix's popularity. >> The Amiga can't even do that. It doesn't have an MMU. >To quote the well known UNIX wizard Deven Thomas Corzine, "The 2500UX already >does." So do all other 2500s. Yes, those specific models have MMU's (hardly utilized under Exec as of yet) but Amigas *as a class* do not have MMU's. And without an MMU, you can not page. You CAN swap without an MMU, but it makes things complicated. (aside from swapping being complicated in and of itself.) If you have the Unix programmer (and user) interface, without paging or swapping implemented, and the whole thing implemented on top of Exec as a base, I think you'll find comparable speeds. After all, what's really left to slow it down much? Not much, except when it comes to fork(), where you have to start swapping around memory for the running task, which IS a significant performance hit. But not likely to be *too* bad if soon followed by an exec()... >> If you ran Unix on the Amiga without paging (which isn't possible) or >> swapping (which is quite possible, but only really feasible with a HD) >> you will get similar speeds to programs running on the Amiga under >> AmigaDOS. >You CAN'T run UNIX without paging, that's part of the task swap overhead >in UNIX, and one of the reasons it goes slower (and, of course, this >slowdown also makes fork() possible, so it's not a clear loss. But what >is?). I'm not at all claiming that it goes considerably slower, just >slower. Also, once you start swapping, obviously, you will go slower. >It doesn't take that many programs running to start swapping. Care to >guess how may programs I have running on my Amiga system here (if you >guessed 35, you'd win the cupie doll). I'm using less than 1.7 >megabytes of RAM. Shared libraries sure make a difference. Swapping and paging are by no means *necessary* components of Unix. (Fine, maybe they are by some official definition, but not by mine.) Unix ran on PDP's in its early days... Was paging actually implemented? (I believe the hardware was able to support it, but I'm not so sure it was actually done.) Eliminate the swapping and paging from Unix, and you've also eliminated most of the extra task-switch overhead. Which should leave the speeds roughly comparable. >>> Consider the problems of expanding wildcard in the shell: >>> - increditably long lines are passed around. >> So? Either the shell builds an incredibly long line and pulls the >> parameters from it to pass to the program, or you pass the program the >> command line directly (as the CLI does) and the program builds the >> same incredibly long line. Big lot of difference it makes. >I thought you said you understood pipes? It makes a big difference. *sigh* Sarcasm will get me nowhere. Granted, it makes a difference. It matters whether the program processes each match as it finds it, or just goes ahead and builds a full list like the shell must. However, I don't think it really makes enough of a difference to outweigh other benifits of keeping the wildcards in the shell. Clearly debatable. I will concede that it makes a far larger difference given a file system structured as the OFS is; the overhead is much greater to scan a directory first, and then process the files, being that the FileInfoBlock will likely have to be loaded twice (unless you have a large cache or a small directory).. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
deven@pawl.rpi.edu (Deven Corzine) (03/23/89)
In article <6359@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <6352@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>In article <DEVEN.89Mar20115205@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: >>> Your assumption that Unix is inherently slow is patently absurd. >> >>Untrue. The Amiga Exec is just plain more efficient than the AT&T UNIX >>Kernel. Task swaps under exec are extremely light weight when compared to >>UNIX swaps. FFS runs around 3x the speed of the standard System V file >>system, on the same A2500 hardware, without swapping in the way (at least >>that was the last rough figure -- don't know if Steve's latest have >>recently been compared with Mike/Johann's latest, but I wouldn't expect >>too much change). Despite what the UNIX-or-death folks say, UNIX isn't >>perfect. >Absolutely true. An important thing to remember though, is that when you >point to particular areas where OS "X" is better than OS "Y", you have to >figure out how much those areas come into play in what you consider >"normal use." Having a more effecient kernel only helps to the extent >that the system spends time in the kernel. Oh, good. I'm not alone. >For example, if you run one CPU intensive program under AmigaDos, and an >equivalent program under Unix, with nothing else running on either system, >the ineficciencies in a Unix task switch won't matter and the difference >between the systems will be negligible. However, In a situation with >several remote users logged in to the the system via telnet, where there >are a few context switches for every keystroke, Unix will start to feel >the overhead in a context switch, and the effective CPU speed will start >to drop. Ironically, AmigaDos is not appropriate for such use (multiple >interactive users) and its advantages there are seldom seen, but those >advantages do come into play with things like applications that run in >multiple processes, etc. >For another example, consider a program which is about half CPU bound and >half file I/O bound. Running this program under AmigaDos (with FFS) and >Unix will show the FFS to be much faster than the Unix filesytem. Run >TEN of these programs simultaneously on each system and I'll bet Unix >will be faster because of things like read-ahead and larger block sizes. heh heh... now try it with the OFS... :-) >>> If you ran Unix on the Amiga without paging (which isn't possible) or >>> swapping (which is quite possible, but only really feasible with a HD) >>> you will get similar speeds to programs running on the Amiga under >>> AmigaDOS. >> >>You CAN'T run UNIX without paging, that's part of the task swap overhead >>in UNIX, and one of the reasons it goes slower (and, of course, this >>slowdown also makes fork() possible, so it's not a clear loss. >Hmm? Deven and Dave both seem to be saying that Unix requires paging, >which isn't true. Unix existed for 10 or 15 years before AT&T released >a paging version. The early versions were "swapping" systems; only an >entire process could be swapped to disk. Paging systems move small pages >of memory to disk when they are not being used. On a paging or swapping >system, it is trivial to configure the system not to use secondary storage >for virtual memory (when all physical memory is in use, attempts to use >more will result in out-of-memory errors). Ambiguous sentence structure. I was saying if you ran Unix on the Amiga without implementing paging (which is impossible *on the Amiga* [ignoring 2500's here]) and without implementing swapping (which you could certainly implement on the Amiga, but is of questionable value, and you would have to be certifiably insane to try swapping to floppies...) then you should get performance rivalling Exec/AmigaDOS. Maybe not quite as good, but definitely in the same ballpark. >>I'm not at all claiming that it goes considerably slower, just >>slower. >I'm not convinced. Unix has things like demand-loading of executables >and shared libraries with demand-copied shared data segments. These are >things that only help in certain situations, but the same is true of >things like fast context switches or file systems optimized for large >sequential reads. All these factors will sometimes pile up toward one >system, making it faster, and they will sometimes balance out. I'm not >convinced that either Unix or AmigaOS is inherently "faster" overall. >And of course, all the above factors are subject to change with new >releases of Unix or AmigaDos; hopefully we'll someday see Unix with >superfast context switches and real time response, and AmigaOS with MMU >address translation, shared text&data segments, automatic stack >allocation, read-ahead, and memory protection. I agree totally here. >> Also, once you start swapping, obviously, you will go slower. >>It doesn't take that many programs running to start swapping. Care to >>guess how may programs I have running on my Amiga system here (if you >>guessed 35, you'd win the cupie doll). I'm using less than 1.7 >>megabytes of RAM. Shared libraries sure make a difference. >I don't see what that has to do with Unix vs. AmigaDos performance, >aside from the additional memory usage of the Unix OS itself. To do >equivalent things with equivalent performance under Unix and AmigaDos, >the Unix system might need another megabyte of RAM to avoid paging. >Then again, it might not, because there are situations where AmigaDos >uses more memory than Unix (such as stack space, for example -- how >many people always use a 10K or 20K stack size because of that >occational program that needs it). Memory fragmentation is another >example. And if you are only one megabyte short on physical memory, I >claim that the paging is not noticable. It might have a slight effect >on some I/O intensive operations, but will generally not effect the >CPU time of programs because memory which is in use is not paged out. >(Unless you are just plain using far more virtual memory than you have >physical memory, and I think we all agree that once you do that, swap >I/O is a fact of life). And the fact remains that Exec current doesn't support paging, so it cannot use more VM than real RAM available. True, a Unix kernel which supports paging will have slower context switches even if everything fits in ram, just because of the overhead to check if paging is needed. On the other hand, the Unix machine can continue to run (albeit slowly) using more memory than it has, which Exec can't do. It's a tradeoff, whichever way you go, you've got advantages and disadvantages. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >has grown to 10, with more expected." ford@kenobi.commodore.com >- The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford > 2nd Edition, June, 1972. ditto@cbmvax.commodore.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ marvelous quote. :-) Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
daveh@cbmvax.UUCP (Dave Haynie) (03/24/89)
in article <6359@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) says: > Summary: Many factors affect performance; > Hmm? Deven and Dave both seem to be saying that Unix requires paging, > which isn't true. Yes, that's true. I know I overstated it, because anyone who's even a bit familiar with UNIX origins knows that early efforts didn't use any form of memory paging. > Unix existed for 10 or 15 years before AT&T released > a paging version. The early versions were "swapping" systems; only an > entire process could be swapped to disk. Paging systems move small pages > of memory to disk when they are not being used. On a paging or swapping > system, it is trivial to configure the system not to use secondary storage > for virtual memory (when all physical memory is in use, attempts to use > more will result in out-of-memory errors). In fact, the very first system designed at Commodore-Amiga, before 68851 MMUs were available, did much the same things. But regardless of whether or not we're actually swapping pages to disk (which, if implemented correctly, all else being equal, looks to me to be always an advantage, never a disadvantage), we always have an MMU context associated with a modern UNIX process. That MMU context makes UNIX processes more expensive than Amiga processes. Depending on the swap granularity, it may not amount to much, but it is additional overhead. >>I'm not at all claiming that it goes considerably slower, just >>slower. > I'm not convinced. Unix has things like demand-loading of executables > and shared libraries with demand-copied shared data segments. These are > things that only help in certain situations, but the same is true of > things like fast context switches or file systems optimized for large > sequential reads. All these factors will sometimes pile up toward one > system, making it faster, and they will sometimes balance out. I'm not > convinced that either Unix or AmigaOS is inherently "faster" overall. There are other areas I didn't touch upon. For instance, all message passing in the Amiga OS is by reference. Under UNIX, far as I know (again, Mike, I openly admit that I'm only somewhat familiar with UNIX, and you are by anyone's measure a true UNIX wizard), most interprocess communication is done by copying, which always more expensive than passing by reference, and unless you can exploit an MMU pseudo-copy, which is basically a pass by reference through an MMU table, it's going to be significantly more expensive. > And of course, all the above factors are subject to change with new > releases of Unix or AmigaDos; hopefully we'll someday see Unix with > superfast context switches and real time response, and AmigaOS with MMU > address translation, shared text&data segments, automatic stack > allocation, read-ahead, and memory protection. That we both agree on. Regardless of the relative speeds, if AmigaOS crashes every time I make a programming mistake (it doesn't, but let's think worst-case here), UNIX will be a faster environment since I loose all that reboot time. >> Also, once you start swapping, obviously, you will go slower. >>It doesn't take that many programs running to start swapping. Care to >>guess how may programs I have running on my Amiga system here (if you >>guessed 35, you'd win the cupie doll). I'm using less than 1.7 >>megabytes of RAM. Shared libraries sure make a difference. > I don't see what that has to do with Unix vs. AmigaDos performance, > aside from the additional memory usage of the Unix OS itself. Well, if you don't have the memory, the difference is speed, and lots of it. Of course, if you don't have the memory on a currently existing AmigaOS system, the difference is between "it works" and "it bombs with an out of memory error". > And if you are only one megabyte short on physical memory, I > claim that the paging is not noticable. I'd really expect that myself, given any decent paging algorithm, just based on the fact that a good portion of any running program isn't going to be running most of the time; maybe not at all. My main complaint is the actual size of the objects. Perhaps not such a big deal in AMIX, I haven't used System V much at all (as a bit of trivia, I used System IV at AT&T one summer, way back, just a bit). But when you start looking at some of the executable sizes for some of the Sun tools that run under their graphics enviromnent, you get a really bad feeling about not using shared libraries. > (Unless you are just plain using far more virtual memory than you have > physical memory, and I think we all agree that once you do that, swap > I/O is a fact of life). And, of course, it lets you do things, however slowly, which would have been impossible without virtual memory. I predict a reasonable form of virtual memory will be available to AmigaOS users who run under A2620 or 68030 systems before the end of the year, possibly much sooner. > -=] Ford [=- -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
daveh@cbmvax.UUCP (Dave Haynie) (03/24/89)
in article <DEVEN.89Mar23022756@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: > In-reply-to: daveh@cbmvax.UUCP's message of 21 Mar 89 07:34:57 GMT > In article <6352@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > Besides, I don't mean specifically the AT&T Unix Kernel. Basically, > what I mean when I say "the Amiga can run Unix" is that you could have > a programming interface virtually identical to that provided in a more > traditional Unix kernel, but you could implement it on top of Exec for > efficiency, power and flexibility. If you're mainly interested in some form of UNIX call-compatible library, whether linked or shared, I whole-heartedly agree. There's so much useful UNIX software out there that's just a little too hard for a busy person such as myself to port over to the Amiga. Most C compilers have link libraries with bits and pieces of UNIX function call compatibility, but nothing that'll handle more than simple ports. > The best of both worlds, as it were. I define Unix more by how it can be > used than by the source code that defines it. Apparently Apollo allows something like function call compatibility for both System V and BSD 4.somthing under Aegis these days. No idea how well it works. UNIX taken from a programming model rather than a user's model is something I'd certainly welcome on the Amiga, if for no other reason than the fast porting of UNIX code that would allow. > >To quote the well known UNIX wizard Deven Thomas Corzine, "The 2500UX already > >does." So do all other 2500s. > Yes, those specific models have MMU's (hardly utilized under Exec as > of yet) but Amigas *as a class* do not have MMU's. And without an > MMU, you can not page. You CAN swap without an MMU, but it makes > things complicated. Well, we have yet to have a version of Exec released since there have been Amigas with MMUs. The MMU could give Amiga systems virtual memory and some level of protection, without necessarily causing problems on systems without MMUs. The MMU lets you swap transparently to application software, without resorting to double pointers (ala Macintosh). It makes things much more efficient; doing the whole thing in software sounds like big time trouble. > If you have the Unix programmer (and user) interface, without paging or > swapping implemented, and the whole thing implemented on top of Exec as a > base, I think you'll find comparable speeds. In my opinion, you're still benchmarking the Amiga OS at that point, just accessed via a slightly different interface. If you started using messages through filesystem pipes or whatever, instead of Exec Messages, you'd go slower. But if you're building UNIX call compatible message passing functions on top of Exec Messages, than you'll of course be within a function call or so of the speed of plain Exec. Similarly, if you decide to implement the System V filesystem and limit transfers to 1K at a time, like AMIX does (or at least did; maybe 1K isn't a fixed limit), your disk speed may drop; but if you implement UNIX compatible disk calls on top of FFS, you're obviously a function call away from AmigaOS speeds. No argument here, except on whether what you're running can be called UNIX or not. > Swapping and paging are by no means *necessary* components of Unix. > (Fine, maybe they are by some official definition, but not by mine.) > Unix ran on PDP's in its early days... Was paging actually > implemented? No, and it isn't on 80286 machines either. I think PDP's had to dump one process to disk and get the other, or some such ugliness. I believe (again, not the UNIX expert here) that the requirement is basically that all processes start at the same location, by whatever means that can be achieved. Paging seems to be the best way; even '386 systems use it instead of segments when running UNIX. If you're not using some form of memory management, even if you don't call it memory management, I don't think you're really UNIX. > Deven -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
deven@pawl.rpi.edu (Deven Corzine) (03/25/89)
In article <6394@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <DEVEN.89Mar23022756@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) says: >If you're mainly interested in some form of UNIX call-compatible library, >whether linked or shared, I whole-heartedly agree. There's so much useful >UNIX software out there that's just a little too hard for a busy person such >as myself to port over to the Amiga. Most C compilers have link libraries >with bits and pieces of UNIX function call compatibility, but nothing that'll >handle more than simple ports. Basically, I want the call compatibility; the internal structure is comparatively igsignificant and could be implemented in a number of different ways anyhow. What most defines it is the system calls, libraries and shells/filters/utilities. The system calls provide the base for all the rest. I want to implement the system calls, some of the library calls and a number of filters (including sed) and some utilities and a shell. Then I'll be fairly happy for a while. And yes, the ability to port Unix code fairly directly was a huge point in the whole thing in the first place, most of why I refuse to implement the functionality but typecasting it to Amiga calls, by using an "Execute.device" with an OpenDevice call and IOrequests to handle the exec() call. That's not what I want. I want the functionality AND the semantics of the Unix calls. [I don't like to type UNIX, myself; seems too much like yelling... :-)] There are a few calls where it doesn't make sense to try to implement them correctly; brk() comes to mind. malloc(), realloc() and free() WILL be implemented, however. (And just HOW often is brk() used?) [indirectly through sbrk() and malloc() doesn't count here; malloc() will call AllocMem.) >> The best of both worlds, as it were. I define Unix more by how it can be >> used than by the source code that defines it. >Apparently Apollo allows something like function call compatibility for both >System V and BSD 4.somthing under Aegis these days. No idea how well it >works. UNIX taken from a programming model rather than a user's model is >something I'd certainly welcome on the Amiga, if for no other reason than >the fast porting of UNIX code that would allow. That's the idea... (Plus, I see it as being valuable for new code as well.) >Well, we have yet to have a version of Exec released since there have been >Amigas with MMUs. The MMU could give Amiga systems virtual memory and >some level of protection, without necessarily causing problems on systems >without MMUs. The MMU lets you swap transparently to application software, >without resorting to double pointers (ala Macintosh). It makes things >much more efficient; doing the whole thing in software sounds like big >time trouble. Certainly. I didn't say or imply that Exec couldn't make use of an MMU; merely that it does not, at present. I rather expect that to change, sooner or later. >> If you have the Unix programmer (and user) interface, without paging or >> swapping implemented, and the whole thing implemented on top of Exec as a >> base, I think you'll find comparable speeds. >In my opinion, you're still benchmarking the Amiga OS at that point, just >accessed via a slightly different interface. If you started using messages >through filesystem pipes or whatever, instead of Exec Messages, you'd go >slower. But if you're building UNIX call compatible message passing functions >on top of Exec Messages, than you'll of course be within a function call or >so of the speed of plain Exec. Similarly, if you decide to implement the >System V filesystem and limit transfers to 1K at a time, like AMIX does (or >at least did; maybe 1K isn't a fixed limit), your disk speed may drop; but >if you implement UNIX compatible disk calls on top of FFS, you're obviously >a function call away from AmigaOS speeds. No argument here, except on >whether what you're running can be called UNIX or not. Of COURSE you're still benchmarking the Amiga OS at that point. which is the entire point of the matter; the speeds would have to be comparable. And as I define Unix compatibility more by the system calls available to the programmer than the internal structure used for the Operating System itself, you've still basically got Unix, but with the performance advantages of Exec supporting it. (Along with the REAL low-level stuff done already, like interrupt handling [rather poorly done, I'm afraid -- GURUs are a pretty piss-poor way to handle a program messing up and causing an address error or something. if it tromps all over system structures, then it's a more reasonable action.] and device drivers which work...) And yes, the filesystem pipe() created pipes WILL be internally implemented using Exec messages. How else? Of course it can't be called Unix -- "Unix" is a registered trademark of AT&T and Bell Laboratories. Xenix can't be called Unix, either, but it basically is. [Nevermind that it WILL soon be called Unix...] >> Swapping and paging are by no means *necessary* components of Unix. >> (Fine, maybe they are by some official definition, but not by mine.) >> Unix ran on PDP's in its early days... Was paging actually >> implemented? >No, and it isn't on 80286 machines either. I think PDP's had to dump one >process to disk and get the other, or some such ugliness. I believe >(again, not the UNIX expert here) that the requirement is basically >that all processes start at the same location, by whatever means that >can be achieved. Paging seems to be the best way; even '386 systems use >it instead of segments when running UNIX. If you're not using some form >of memory management, even if you don't call it memory management, I don't >think you're really UNIX. The PDP's probably did something fun like that. And you could do the same on an Amiga, though I wouldn't really want to. Actually, I'm pretty sure the PDP's had memory protection to some extent but NOT support for paging... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
andy@cbmvax.UUCP (Andy Finkel) (03/29/89)
In article <DEVEN.89Mar25005229@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >REAL low-level stuff done already, like interrupt handling [rather >poorly done, I'm afraid -- GURUs are a pretty piss-poor way to handle >a program messing up and causing an address error or something. if it As I recall, the 68000 has a bit of trouble recovering from an address error. (not enough state info saved). This was fixed in the 68010. (wasn't there a 68000 computer that used 2 68000s to get around this one ?) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Give me a Standard large enough, and a Committee to discuss it, and I will prevent the Earth from moving." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
daveh@cbmvax.UUCP (Dave Haynie) (03/30/89)
in article <6411@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) says: > In article <DEVEN.89Mar25005229@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >>REAL low-level stuff done already, like interrupt handling [rather >>poorly done, I'm afraid -- GURUs are a pretty piss-poor way to handle >>a program messing up and causing an address error or something. if it > As I recall, the 68000 has a bit of trouble recovering from > an address error. (not enough state info saved). > This was fixed in the 68010. (wasn't there a 68000 computer > that used 2 68000s to get around this one ?) It's actually bus error that's the problem. An address error is a programming error of some kind, and that can be caught, and the program removed, given a sufficiently enthusiastic operating system. For virtual memory, though, you have external logic generate a bus error if you try to access memory that's swapped out. The problem is that the 68000 bus error doesn't save enough state to either retry or continue the instruction, so real VM just plain won't work on a single 68000. Our old Apollos used the 2 68000 trick to support virtual memory. All the currently used Apollos here are based on a bit-slice machine that emulates a 68010. Hopefully soon we'll have some that can keep up with our Amigas... > andy -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
deven@pawl.rpi.edu (Deven Corzine) (03/30/89)
In article <6411@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >As I recall, the 68000 has a bit of trouble recovering from >an address error. (not enough state info saved). >This was fixed in the 68010. (wasn't there a 68000 computer >that used 2 68000s to get around this one ?) This could be. There are other more blatent situations where bringing down the entire machine is NOT necessary -- such as freeing memory already freed... [True, some note should be made, and the user perhaps warned, in case the system is actually fried, a time bomb just waiting to explode... but it shouldn't just crash.] Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
dlm@druwy.ATT.COM (Dan Moore) (03/30/89)
in article <6411@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) says: > As I recall, the 68000 has a bit of trouble recovering from > an address error. (not enough state info saved). > This was fixed in the 68010. (wasn't there a 68000 computer > that used 2 68000s to get around this one ?) The real limitation on the 68000 is lack of state information after a buss error. The MMUs all generate buss errors when an access to unmapped RAM occurs, that's so the OS can swap a page to/from disk. Motorola sent out a tech report describing how to use two 68000s and a 68451 MMU. The first 68K ran the user programs, instead of causing it to buss error the 68451 would wait state it and cause the second 68000 to take over. The second 68000 would then fix the memory fault by swapping to/from disk and then allow the first 68000 to resume execution of the user code. I wonder if anyone ever really built a system that worked that way. Dan Moore AT&T Bell Labs Denver dlm@druwy.ATT.COM
david@ms.uky.edu (David Herron -- One of the vertebrae) (03/31/89)
In article <6394@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >No, and it isn't on 80286 machines either. I think PDP's had to dump one >process to disk and get the other, or some such ugliness. I believe >(again, not the UNIX expert here) that the requirement is basically >that all processes start at the same location, by whatever means that >can be achieved. Paging seems to be the best way; even '386 systems use >it instead of segments when running UNIX. If you're not using some form >of memory management, even if you don't call it memory management, I don't >think you're really UNIX. >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession Not quite -- as long as we're discussing history of old machines that is. The PDP-11's either had memory management or didn't. We had a PDP-11/05 (or was it a /20?) that didn't have memory management on which we ran a version of V6 specially built for such machines. There was some way that it could have more than one process in memory at a time but without memory management. I can't think of how it could've been done right off the top of my head -- but I know there wasn't memory management because the kernal could be corrupted by wild pointer references ... er.. maybe it couldn't fit in more than one process at a time. In any case there was only 16K of memory (words, not bytes, 32Kbytes) for programs once the 16K (32K) was taken out for the OS. And to 'swap' whole processes were swapped out. Other PDP-11's *did* have a memory manager which provided mapping of 8 segments in the 64kbyte address space. (8kbyte segments). Some PDP-11's even had lots of memory (up to 4 megs if I remember right). (Hmmm... my A2000 has 3 megs in it -- my how time changes things ...) On these machines you could easily have many programs in memory. But again it could only swap out whole processes. Proper paging virtual memory didn't come until some version of 4.x (4.2?) in the BSD strain and in SysVr2.(something) in the SysV strain. To answer a previous question ... And yes, Unix passes messages by copying. Twice in fact. Once from the sender to the kernel, and again from the kernel to the receiver. An important addition is that on Unix the receiver could just as easily be some process in Norway on the Internet as it could be some process on the local machine. *THAT* is *MY* wish for AmigaDOS 1.4 (or ASAP anyway) -- convenient message passing across machines. Oh yeah. In a Unix context message passing *could* be done w/o copying. er.. well, fewer copies anyway. You set up a shared memory segment in the system between the cooperating processes. Probably to get the data into the shared memory you do a copy, then to get it back out there's another copy. This is because the area in the shared memory is limited resource that you don't want to waste needlessly. But in any case, a convention could be built allowing communication through such a thing. Doesn't the AmigaDOS convention of passing pointers to objects around lead to problems with resource management? That is, when it comes time to kill a process how do you free the memory associated with that process? If one process creates some object and then gives it to another -- does the kernel keep track? And can't the object be shared between processes? -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- The problem with mnemonics is they mean different things to different people.
daveh@cbmvax.UUCP (Dave Haynie) (04/01/89)
in article <11370@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) says: >>If you're not using some form of memory management, even if you don't call >>it memory management, I don't think you're really UNIX. >>Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > Not quite -- as long as we're discussing history of old machines that is. > The PDP-11's either had memory management or didn't. We had a PDP-11/05 > (or was it a /20?) that didn't have memory management on which we ran > a version of V6 specially built for such machines. There was some way that > it could have more than one process in memory at a time but without memory > management. I can't think of how it could've been done right off the top > of my head -- but I know there wasn't memory management because the kernal > could be corrupted by wild pointer references ... I didn't say memory management was necessarily in hardware, though I believe that hardware memory management is necessary for a UNIX the performs to modern specifications. Clearly, if you're running more than one process at a time, but only one's in memory at a time, there is memory management happening; each process believes it starts in the same place. Paging would only make the performance reasonable. > And yes, Unix passes messages by copying. Twice in fact. Once from > the sender to the kernel, and again from the kernel to the receiver. > An important addition is that on Unix the receiver could just as easily > be some process in Norway on the Internet as it could be some process > on the local machine. I knew UNIX passed messages by copying, but didn't consider, though it's obvious if you think about it, that it would have to be two copies. > Doesn't the AmigaDOS convention of passing pointers to objects around > lead to problems with resource management? I think so. But it's fast.... > That is, when it comes time to kill a process how do you free the memory > associated with that process? I think the only proper way for an Amiga process to die is by suicide. The process knows what resources it's allocated, so it deallocates them and then RTSs or some-such. > If one process creates some object and then gives it to another -- does the > kernel keep track? No. > And can't the object be shared between processes? Theoretically, yes, though that's bad programming practice. If someone send me a message, it's mine, and mine alone, until I reply to the message, at which point, I'm not supposed to touch it again. So what usually happens is, you get a message. If there's stuff you can use immediately, you do so. Otherwise, if the reply time is cricitical, you copy what you need to local storage, then reply. Of course, it's not always going to be that you've got some party waiting on the other end to actually do anything. > <- David Herron; an MMDF guy <david@ms.uky.edu> > <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET > <- The problem with mnemonics is they mean different things to different people. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
farhi@athena.mit.edu (Bill Hoston) (04/01/89)
Quoting Dan Moore in <3945@druwy.ATT.COM>: > Motorola sent out a tech report describing how to use two 68000s >and a 68451 MMU. The first 68K ran the user programs, instead of >causing it to buss error the 68451 would wait state it and cause the >second 68000 to take over. The second 68000 would then fix the memory >fault by swapping to/from disk and then allow the first 68000 to resume >execution of the user code. > I wonder if anyone ever really built a system that worked that >way. If I remember correctly, a recent thread on comp.sys.m68k said the first Sun's used such a method. I don't know all the details (wish I did). Bill Hoston farhi@athena.mit.edu
elg@killer.Dallas.TX.US (Eric Green) (04/02/89)
in article <6411@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) says: > As I recall, the 68000 has a bit of trouble recovering from > an address error. (not enough state info saved). > This was fixed in the 68010. (wasn't there a 68000 computer > that used 2 68000s to get around this one ?) The two 68000's trick was a common one. I believe that the original Sun used it. I'm absolutely certain that the original Stratus 68000-based fault-tolerant system did it (a friend of a friend was involved in that design). But that's really irrelevant as concerns recovering from an address error. Recovering from an address error really makes sense only when you have virtual memory. The Amiga doesn't have virtual memory. Ergo, it doesn't make sense. Since Exec and AmigaDOS have no resource-tracking facilities, there isn't any good way to restore the system to a "clean" state after an address error. The Guru really is the best way to handle it. However, I do very much hate the current GURU. If you're going to barf, at least put a nice little alert up like GOMF, telling which task and process was running when the system choked, and other relevent information. I hear that this is going to be in 1.4, or at least some future Amiga release... I'm glad. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |
daveh@cbmvax.UUCP (Dave Haynie) (04/05/89)
in article <0912.AA0912@julie>, mcr@julie.UUCP (Michael Richardson) says: > Subject: > Out of curiosity, why weren't the 500 and 2000 just released > with 68010s? I am pretty sure that even the 1000 could have been > released with one, and given that it is possible to just > drop one in, all that would have been required was a software > change (easy in the 1000 days.) No software change would be necessary. > My only explanation would involve cost/benefit. It just wasn't worth the > added expense... That's certainly a part of it. At least when the A1000 went out, I recall 68010s went for about $50.00, vs. $5.00 for the 68000. Also, there'd probably be a problem getting enough -- the 68010 isn't second sourced, far as I know, and Motorola never did a huge business in 68010's, since they were followed up pretty closely by the 68020. The only machines I've even seen that come standard with 68010 are the Sun 2 and the host machine for the Tektronics DAS analyzer I use in the lab. Apollo used a bitslice emulation of one in some of their machines, but none of these applications approach the high volumes of the 68000. Plus, without some form of address translation (eg, an MMU, even a simple one like in the Sun 2), the capability to continue instructions on a bus error doesn't have all that much use. > :!mcr!: > Michael Richardson Amiga > v--------+ > UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca > Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
michael@maui.cs.ucla.edu (michael gersten) (04/14/89)
In article <6490@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
:In article <0912.AA0912@julie>, mcr@julie.UUCP (Michael Richardson) says:
:
:> Out of curiosity, why weren't the 500 and 2000 just released
:> with 68010s?
:
:No software change would be necessary.
Wrong. The 68010 has one instruction privleged that was not privledged
on the 68000. This kills early versions of Lattice's math library,
and some games.
Michaeljbwaters@bsu-cs.bsu.edu (J. Brian Waters) (04/14/89)
In article <22977@shemp.CS.UCLA.EDU>, michael@maui.cs.ucla.edu (michael gersten) writes: > In article <6490@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > :In article <0912.AA0912@julie>, mcr@julie.UUCP (Michael Richardson) says: > : > :> Out of curiosity, why weren't the 500 and 2000 just released > :> with 68010s? > : > :No software change would be necessary. > > Wrong. The 68010 has one instruction privleged that was not privledged > on the 68000. This kills early versions of Lattice's math library, > and some games. Um they mean OS software changes... and programs that used the move ccr,<ea> instruction went against the Amiga programming rules. They would not work with a 68020 either... in fact I think CA should have put a 68010 in at least the 2000 for just this reason. It would have made sure that programers would have fixed this more quickly. Just as the release of machines with non-chip ram got many program fixed in that area. -- Brian Waters <backbone>!{iuvax|pur-ee}!bsu-cs!jbwaters
skipper@xroads.UUCP (Skipper Smith) (04/15/89)
In article <22977@shemp.CS.UCLA.EDU>, michael@maui.cs.ucla.edu (michael gersten) writes: > In article <6490@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > :In article <0912.AA0912@julie>, mcr@julie.UUCP (Michael Richardson) says: > : > :> Out of curiosity, why weren't the 500 and 2000 just released > :> with 68010s? > : > :No software change would be necessary. > > Wrong. The 68010 has one instruction privleged that was not privledged > on the 68000. This kills early versions of Lattice's math library, > and some games. > > Michael The only instruction that was changed was the MOVE.W SR,<ea> which copies the entire status register into some effective address. Any program which does not make use of that instruction (and only while running in USER mode) will work perfectly- as long as it is user code. Because of the different sized stack frames (which some people like to pick information off of) that are created during exception processing, some supervisor code (read OS) would have to be modified, but it is (depending on how gung ho people are) fairly trivial. By adding the 68010, the Amiga would have gained the capabilities to use virtual memory and create virtual machines. For those who don't know what a virtual machine is, suffice to say that the problem (?) of running UNIX under AmigaDOS could have fairly easily (as a guess only, I am no expert on this topic) circumvented. Oh yes, it is the MOVE.W SR,<ea> that causes that problem. I personally could care less about running UNIX and AmigaDOS at the same time since I don't have 5-9 Mb of RAM to make it work reasonably well, but I would sure like to be able to use the unused portions of a 380 Mb hard drive (I got a good deal, ok?) for virtual memory until I can get that extra RAM. Skipper Smith Motorola Technical Training Tempe, AZ (Please send all comments/flames/etc... directly to me, as I travel a great deal and just might skip over it while trying to read through the plethora of net.junk that accumulates over a couple of weeks) -- \ / C r o s s r o a d s C o m m u n i c a t i o n s /\ (602) 941-2005 300|1200 Baud 24 hrs/day / \ hplabs!hp-sdd!crash!xroads!skipper
daveh@cbmvax.UUCP (Dave Haynie) (04/19/89)
in article <22977@shemp.CS.UCLA.EDU>, michael@maui.cs.ucla.edu (michael gersten) says: > In article <6490@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > :In article <0912.AA0912@julie>, mcr@julie.UUCP (Michael Richardson) says: > :> Out of curiosity, why weren't the 500 and 2000 just released > :> with 68010s? > :No software change would be necessary. > Wrong. The 68010 has one instruction privleged that was not privledged > on the 68000. This kills early versions of Lattice's math library, > and some games. > Michael No, you're wrong. So are any programs that have your aforementioned problem. Since before AmigaOS V1.0, there's been a system call that takes care of the incompatibility you mention, that of the 68000's MOVE SR,<ea> versus the 68010 and greater MOVE CC,<ea>. Exec solves this problem with the GetCC() function call. Any program that uses either direct instruction is not conforming to the Amiga OS specifications, and as such is not a valid Amiga program. So I stand by my original contention that no software change is necessary. Any program that has a dependency on this issue also has a bug that need fixing, plain and simple. It indicates that the programmer just didn't read the system documentation. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
daveh@cbmvax.UUCP (Dave Haynie) (04/19/89)
in article <626@xroads.UUCP>, skipper@xroads.UUCP (Skipper Smith) says: > Summary: That minor change > By adding the 68010, the Amiga would have gained the capabilities > to use virtual memory and create virtual machines. For those who don't know > what a virtual machine is, suffice to say that the problem (?) of running > UNIX under AmigaDOS could have fairly easily (as a guess only, I am no expert > on this topic) circumvented. Oh yes, it is the MOVE.W SR,<ea> that causes > that problem. Not really. Virtual memory only works when you have an MMU of some sort. While some instruction restart or continuation capability, as you get with the 68010, is a necessary precondition to running a virtual memory system, it's not sufficient on it's own to support such a system. Running UNIX under AmigaOS, or visa-versa, is a much higher level problem that dealing with condition codes. For example, many aspects of AmigaOS depend on the realtime response it delivers, which would disappear under UNIX. UNIX, on the other hand, requires things that would certainly trip up AmigaOS's Exec. And if you got UNIX working under AmigaOS somehow, your UNIX would still be subject to crashes by errant AmigaOS programs. To really get both working simultaneously, if it's even possible (eg, Dave != The Software Architect Of All This, I just build the hardware that makes the discussion worthwhile), would probably require some kind of superkernel that manages both operating systems. > since I don't have 5-9 Mb of RAM to make it work reasonably well, but I would > sure like to be able to use the unused portions of a 380 Mb hard drive (I got > a good deal, ok?) for virtual memory until I can get that extra RAM. If you have a 68020+68851 (like the A2620) or some 68030 system, this could be done. I'm not about to say it's easy, just possible. Without an MMU of some sort, forget it (an obvious conclusion if you really think about virtual memory and how it would have to work under the Amiga OS). > Skipper Smith -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
sparks@corpane.UUCP (John Sparks) (04/20/89)
In article <6625@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: [about the incompatibility between 68000 and 68010] > Any program that has a dependency on this issue also has a bug that need > fixing, plain and > simple. It indicates that the programmer just didn't read the system > documentation. You mean, like, hmm, oh.. I don't know, like for instance the TRANSFORMER?!? -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps [not for RHF] | sparks@corpane.UUCP | 502/968-5401 thru -5406 The next sentence is true. The previous sentence is false.
wtm@neoucom.UUCP (Bill Mayhew) (04/21/89)
I put a 68010 in my Amiga 1000 for a while. I noticed that up though version 1.2 of the O/S, there were a nontrivial number of programs that seemed to be using MOVE CC,<ea> instruction. I've seen a number of E-A games that break, but then they hog the whole machine anyway. The Amiga Transformer also craps out with a 68010 installed. I put the 68000 back in because the real world performance difference between the 68000 and the 010 was less than 10% reduction in execution time. Of course, one can contrive a program that takes advantage of the loop optimization of the 68010 and show a bigger difference than that, but that isn't the real world on the Amiga. Bill
drc@CSUStan.EDU (Dave Coughran) (04/23/89)
In article <1588@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >I put a 68010 in my Amiga 1000 for a while. I noticed that up though >version 1.2 of the O/S, there were a nontrivial number of programs >that seemed to be using MOVE CC,<ea> instruction. I've seen a >number of E-A games that break, but then they hog the whole machine >anyway. The Amiga Transformer also craps out with a 68010 >installed. > [rest deleted] I have a friend with a 68010 in his machine, and he could not get Blackhawk(?) 1942 to run. It gave him a "Not a DOS Disk" requestor but ran fine on my 68000. Both are Amiga 1000's BTW. Does anybody know if this behaviour is a 68010 problem or if there might be something else funny with his machine? Also, He told me that Supra told him he needed the 68010 for his hard disk to work properly. Anybody know if this is true? Sounds fishy to me. Any help/suggestions would be appreciated. >Bill --David Coughran {ames,uunet}lll-winken!csustan!drc PLINK:David-C