dillon@ucbvax.BERKELEY.EDU (Matt Dillon) (01/19/86)
Time to start a new discussion. What do all you C programmers think about the OS? Now that I have had a chance to get into it, I have some comments I would like to make. First of all, for programming ease, the Amiga OS is total shit when compared with UNIX. Not only are no checks made on input parameters, but the OS itself isn't very robust. I have noticed, for instance, that if you give DoIO() bad parameters, or even simply call BeginIO() without doing an AbortIO() (mainly the serial port) when there was something else going on, the Serial port device driver gets lost and crashes the system. The OS doesn't keep track of what your process is doing, and thus you must FreeMem, CloseLibrary... etc... everything you opened before you exit, or those resources will be lost forever. This means, of course, that the Amiga cannot simply KILL a process (as someone suggested as an improvement). Many simple operations on the Amiga take many more lines of code than they should. For instance, openning windows, screens, or simply attempting to get SOME control over the serial port takes mucho code which goes very deep into the OS. This coupled with the instability and lack of error recoverability in the OS makes for quite a few machine crashes. The generalized I/O concept on the Amiga is too complex. To have any control over a resource (screens, windows, serial port), you are required to include GOBS of files, make innumerable system calls; and although these give you full control over the resource in question, they are generally very slow, and not fully implimented. The filesystem (basis for quite a lot), is a good example. The lack of IOCTL()s is very apparent. It looks as though the generalized Port() replaces that elegant call. There is no truncate() (or did I miss something??), nor is there an easy way to pass file structures around. The Execute() utility requires c:run to exist (a definate no-no), and the standard input/output devices are the exception rather than the rule. The programmer is required to delve deep into the Operating system to do a simple 'Change Directory', and even processes have distinct special cases. In my opinion, the CLI should have been more like CSH, with the base standard I/O and execute functions built into the OS rather than the CLI. Having easily changeable devices is nice, and you could theoretically have your own RAM: device, but they would have best been placed in the kernal rather than as separate processes. The Amiga OS is NOT a real-time operating system. (I'm sorry, it just isn't). I had one process running continuously, doing lots of system calls, and a seek on the disk took... well, to put it bluntly, it didn't happen until I killed the process. Such things as disk and serial I/O should have been completely interrupt driven. Not only would everything speed up, you would get a cleaner system. For those of you who have knowlege of the 4.2BSD kernal, or another UNIX like kernal, you would appreciate what has been accomplished. The basic idea is 'multi tasking user proceses, single tasking kernal', with everything interrupt or timer driven. As an example, the 4.2 kernal's device drivers may request they be called in 30 seconds, or 1/30 of a second (device driver's aren't seperate processes, but they can get service at time intervals). The reason you get much better throughput with this scheme, is that there is no idle time wasted. If something in the kernal blocks, the OS simply sleeps itself (allowing other processes to run) until the resource is freed. Thus, the device driver is driven both by low-level interrupts, and by calls to it by the kernal requesting read's, write's, ioctl's, etc... That is the way I would have liked to see the Amiga kernal, but Alas, it was not to be. --Going back to the filesystem-- What I miss most in the Amiga is the lack of a SELECT() system call, and easily implimented NON-BLOCKING I/O, plus a slight enhancement of the Read() system call. The call should return whatever is available rather than wait till the entire buffer you specify is full. File operations should be considered 'non blocking'. This is what UNIX does. I realize there is a comparable Wait() call for the Amiga, but it isn't generalized AT ALL. SELECT() is. You select on file descriptors, period. with Wait(), you have to dig into the OS. The ':' base (in addition to file path's) are a nice combination, but the directories should have implimented '.' and '..'. Additionaly, the directory entries are way too large. I tend to guess that almost no thought was given to them... tell me, a COMMENT entry??? say what? -------- ICONS ----- Graphics in general Of course, the HARDWARE is fantastic, and in fact the one major reason I bought my Amiga. The graphics support routines are excellent too. However, they are not generalized enough at the programmer's end, and check almost nothing about the validity of the data they are processing. I get the feeling that who-ever designed the Amiga OS didn't have much experience with multi-tasking or High Level languages. Apart from the PASCAL like style of all the include files, and the PASCAL like style of the basic Open() function, I would tend to want to throw every .H file away and re-write them. ---- But the Amiga people are to good to have created some of the things I have seen. What happened??? By the look of it, somebody but the bolt on the entire system... not allowing any major design changes after the first prototype was got working (and I'm talking internal prototype's... with release still years away). Could somebody shed some light on this? --- LIBRARIES, etc... The concept of libraries is not new. My complaint on their usage on the Amiga is simple: The intuition library should not be a library. The graphics library should not be a library. They should have been system calls. The programmer should not have to OpenLibrary() them, period. There are way too many programmer-"required to know about and use" structures. The system calls should have been implimented on a much higher level. Welcome to the world of OS-design, -Matthew Dillon
fnf@unisoft.UUCP (Fred Fish) (01/21/86)
In article <11448@ucbvax.BERKELEY.EDU> dillon@ucbvax.BERKELEY.EDU (Matt Dillon) writes: > >with the base standard I/O and execute functions built into the OS rather ^^^^^^^^^^^^^^^^^ >theoretically have your own RAM: device, but they would have best >been placed in the kernal rather than as separate processes. The ^^^^^^^^^^^^^^^^^^^^ >usage on the Amiga is simple: The intuition library should not be >a library. The graphics library should not be a library. They should >have been system calls. The programmer should not have to OpenLibrary() ^^^^^^^^^^^^ Caution, your Berkeley orientation is showing through. ls -l /vmunix -rwxr-xr-x 1 root 308224 Jan 13 20:03 /vmunix* Lets not shovel everything into the kernel just because it's there. -Fred
perry@atux01.UUCP (P. Kivolowitz) (01/21/86)
Matt Dillion thinks AmigaDos is ``total shit'' and believes that Unix is the god which all o.s. must emulate. Basing his opinions on the that he professes to be an expert kernel hacker he thinks all should be thrown out (except for a few graphics routines) and we should start again. Well, Matt, I don't know if you are a Unix expert and, in fact, your exp- ertise in operating system X doesn't really bear upon the argument at hand. Unix is not Tripos. And similarly, Tripos is not Unix. I think your views are too restrictive (read that narrow minded). The answer to statements like ``Unix is great because...and AmigaDos is shit because...'' are senseless and without worth. The two operating systems address different needs. Maybe you are a UNIX expert, Matt, but you definately are not an AmigaDos expert. In many ways, the kernel underlying the nifty imagery, possess truely state-of-the-art concepts in operating system design. You'd see that too if you'd not look through Unix colored glasses. --------------- No personal aspersions intended here nor do I believe any were cast. And, I don't know why you couldn't get in a disk access while other processes were going on - but I'd suggest it was something you were doing wrong since examples of doing just that abound - like running musicraft while copying or formatting disks. Perry S. Kivolowitz
mykes@3comvax.UUCP (Mike Schwartz) (01/21/86)
As someone relatively new to both Unix and AmigaDos, I have found that the similarities are very strong. However, at deeper levels, Unix and its 10+ years of maturity is better polished. However, Unix programs require MUCH MORE TIME to learn because the source programs have ZERO comments, and the function names are very short and not very mnemonic. AmigaDos has some of the best written documentation I have ever seen, although it is not always accurate (I expect the documentation will be more accurate in later versions). The source code and header files for AmigaDos are excellent, although verbose. My opinion is that I would rather read the comments, then strip them away, then to not have them at all. The names of all the Amiga functions are very descriptive of their function. I see the Amiga as an attempt to set a new standard in Personal Computers, not as some compromise between old technology and new. The hardware is so unique (no other PC has the same standard features), that the operating system was required to use all of the features of the hardware (something that UNIX does not do due to its generality). The ROM KERNEL seems to contain the proper components to create excellent video games and simulations. The device drivers seem to be a combination of two designs that not all drivers seem to adhere to. For example, I have used CreatePort() to create message ports for serial IO, but not for the Narrator device. AmigaDos is a 68K operating system that was written by MetaComco. It consists of a library, the CLI, and all the other misc. programs that run under it. 99% of the criticism seems to revolve around this piece of code. However, on a large machine (8MB, Hard Disk), I imagine that things will be quite tolerable. However, on a 512K machine, I think we all feel a need for some elbow room. Also, the floppies are just too slow to use with Lattice 'C' in a friendly manner. I agree that there is a lot to learn from an OS like Unix, but I don't care if the Amiga software has nothing in common with it. People keep saying "I wish it were more like Unix..." or "I wish it were more like OS-9...", which immediately indicates some amount of bias towards Unix or OS-9 (to me) and not a constructive point toward the Amiga stuff. Don't forget that all the boys at Amiga have Sun Workstations running Unix, and they write some gorgeous looking 'C' code, and they are not blind to the operating system that drives the Sun! My approach to dealing with the inconsistencies of the operating system was to build an interface to it more to my liking. I have built a library that has routines like rs232_open, rs232_getc, scr_open (open window), scr_putc, etc., which are simpler to call and reduces the number of header files and initialization code (very lengthy stuff) required from program to program. This solution also makes my programs a little more portable, since I am only required to rewrite these routines instead of writing OpenWindow, et al. I view the Amiga and its software as being immature. Given a chance, the machine will be a new standard. AmigaDos sure beats the heck out of MS-DOS (as far as programming it goes), and its multi-tasking gives it a unique look in the PC market. In a couple of years, the best of Unix will be ported, and the worst of AmigaDos will be improved and people will rave about it like they do OS-9 and Unix. I do not have any direct experience with the Mac or ST, but I don't imagine that their programatic interfaces are anywhere near as easy to use as the Amiga's. I see very little technical information (yet alone programs) being posted to net.micro.atari, and the Mac has long had a reputation as being a tough machine to learn.
dillon@ucbvax.BERKELEY.EDU (Matt Dillon) (01/21/86)
Ahh.... yes, the loader is rather slow. Even with lc1 in memory
it takes a couple of seconds to load. That is a definate No No, since
improvement would mean a complete revamping of the system.
>On to the file system: It's cute for a toy computer...
I agree. The filesystem should have been the CORE of the Amiga.
I'm not saying that all OS's need to have the filesystem as a core, but
on the Amiga, it would have been a giant forward leap. Right now, the fs
seems to be only half implimented.
---------------
Somebody posted to the net that I was not being specific enough.
---------------
My dream of the Amiga OS: (Definately Berkeley UNIX Biased)
(A) UNIX like filesystem
(B) Screens, Windows implimented w/ /dev/ device drivers
(C) I like the extended file-name idea (con:0/0...), put it in
(D) IOCTL'S
I believe in separation between user and hardware, through
file descriptor's and ioctl's, not through system structure's.
-Matthamilton@uiucuxc.CSO.UIUC.EDU (01/21/86)
> Many simple operations on the Amiga take many more lines of code >than they should. For instance, openning windows, screens, or simply >attempting to get SOME control over the serial port takes mucho code >which goes very deep into the OS. >The generalized I/O concept on the Amiga is too complex. back in the early days of unix, the only i/o you had was read() and write(). in order to do buffered, "stream", i/o, you needed GOBS of code. so somebody invented the portable i/o library out of the existing primitives. compare this to pascal which gives you high-level i/o, but no chance to roll your own. > The filesystem (basis for quite a lot), is a good example. The >lack of IOCTL()s is very apparent. It looks as though the generalized >Port() replaces that elegant call. ioctl()? elegant?! >The programmer is required to delve deep into the Operating >system to do a simple 'Change Directory', Lock() and CurrentDir() are no "deeper" that open() and chdir(). it's true that you need to do a Lock() followed by a CurrentDir() to effect a chdir(), but compare what you have to do to find the name of the current directory! > Having easily changeable devices is nice, and you could >theoretically have your own RAM: device, but they would have best >been placed in the kernal rather than as separate processes. why? what difference does it really make whether the devices are distinct processes or interruptable co-routines of a single kernel process? elsewhere you complain that devices and libraries don't do what you want; the way things are set up, _you can write your own_. you can even switch in mid-stream without re-booting! >The >Amiga OS is NOT a real-time operating system. (I'm sorry, it just >isn't). how do you figger that? what does a realtime OS have to have that exec doesn't? >Such things as disk and >serial I/O should have been completely interrupt driven. Not only >would everything speed up, you would get a cleaner system. > For those of you who have knowlege of the 4.2BSD kernal, or >another UNIX like kernal, you would appreciate what has been >accomplished. The basic idea is 'multi tasking user proceses, >single tasking kernal', with everything interrupt or timer driven. >As an example, the 4.2 kernal's device drivers may request they be >called in 30 seconds, or 1/30 of a second (device driver's aren't >seperate processes, but they can get service at time intervals). >The reason you get much better throughput with this scheme, is that >there is no idle time wasted. If something in the kernal blocks, >the OS simply sleeps itself (allowing other processes to run) until >the resource is freed. Thus, the device driver is driven both by >low-level interrupts, and by calls to it by the kernal requesting >read's, write's, ioctl's, etc... ??? so what does this have to do with the amiga? amiga devices (at least, the serial device i've studied most) are also interrupt driven. it's almost SCARY how interrupt-driven the amiga is. have you looked closely at the "interrupt server" concept? >File >operations should be considered 'non blocking'. This is what UNIX does. no, this is what some unixes let you do; i used unix for years without non-blocking i/o. typical file processing doesn't need to be asynchronous; unless you're going to the trouble of multiple-buffering, it doesn't do any good. but, if you really want it, it looks to me like it's there, it's just not handed to you on a platter. [later] upon re-reading this, it occurs to me you may be thinking amigados/exec itself is doing i/o synchronously? that while a disk block transfer is in progress _everything_ else comes to a halt? well, not on _my_ machine. > I realize there is a comparable Wait() call for the Amiga, but it >isn't generalized AT ALL. SELECT() is. You select on file descriptors, >period. with Wait(), you have to dig into the OS. Wait() is not generalized, but select() is?! c'mon! select() works ONLY on file descriptors; Wait() works for any event that posts a signal, and since you can post those signals yourself, it's open to your imagination what you can Wait() for. Wait() combines the functions of: select(), signal()/setjmp(), wait(), pause() and probably a couple others. i can't think of a _more_ general function. > The ':' base (in addition to file path's) are a nice combination, >but the directories should have implimented '.' and '..'. Additionaly, >the directory entries are way too large. I tend to guess that almost >no thought was given to them... tell me, a COMMENT entry??? say what? they do; "/" is "..". i admit to not liking the way the amigados inverts a lot of my (unix) habits. sometimes i wonder if they deliberately sowed landmines for unix freaks. the COMMENT capability is actually a useful touch. besides the canonical describe-the-file, i can see using it to contain arbitrary out-of-band data about a file. for instance, i miss having BOTH creation and modification timestamps. think of it as a programmer-accessible part of the "inode". > The concept of libraries is not new. My complaint on their >usage on the Amiga is simple: The intuition library should not be >a library. The graphics library should not be a library. They should >have been system calls. The programmer should not have to OpenLibrary() >them, period. i completely disagree. i think the library concept is very nice. it's interesting that you say this after expressing your preference for unix, since many of us unix users have wanted a dynamic library capability for years. as for the inconvenience, if you hate it that much, write your own library interface that opens and closes libraries on the fly (the way getpwuid() opens /etc/passwd). > There are way too many programmer-"required to know about and >use" structures. The system calls should have been implimented on a >much higher level. that's the price of flexibility. most of your comments boil down to "dammit, they didn't do it like unix". i've been using unix for 10 years, and much as i like it, i'm willing to try other approaches. the priority given to message passing over procedure calls, for example, is still very new to me. it'll take some time to adjust. i do miss a lot of features of unix, particularly with respect to the file system. however, it seems to me that the file system has been seperated from the rest of the OS to the extent that you can have more that one. if it becomes important enough to me, i'll try writing my own file-handler task. by the way, i notice i have more trouble with amigados than with exec. the one thing i will unreservedly pan is this damn BPTR/BSTR nonsense. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton@uiucuxc.cso.uiuc.edu CSNET: hamilton%uiucuxc@uiuc.csnet USMail: Box 476, Urbana, IL 61801 Phone: (217)333-8703
mwm%ucbopal@BERKELEY.EDU (01/22/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> Seems that whenever people start discussing OS's, and what's good and/or bad about them, they forget that they are talking about at *least* three different things: the OS proper, as seen by systems hackers and sysadmins, the interface for programming language X, and the user interface. For example, when Matt Dillon complains about the following: > From: dillon@ucbvax (Matt Dillon) > One should not need so many include files for simple programs. Why > weren't the generic Read() and Write() routines given these options? Also, > I am quite sick an tired of having to write 40 lines of code just to simply > read all the character's currently in the serial buffer, and NOT block when > there aren't any (or the buffer isn't full... yucc) > > Further gripes: The signalling was done wrong, > The Screen/Window routines are not generic enough, > The Wait(), message, and packet protocols are all > wrong. > > P.S. generic: On the Amiga it takes 40 lines of code to do things > (Like non-blocking I/O) which takes 2 lines of code (an open() and > an ioctl()) on UNIX systems. > > First of all, for programming ease, the Amiga OS is total shit >when compared with UNIX. Not only are no checks made on input parameters, >but the OS itself isn't very robust. I have noticed, for instance, that >if you give DoIO() bad parameters, or even simply call BeginIO() without >doing an AbortIO() (mainly the serial port) when there was something else >going on, the Serial port device driver gets lost and crashes the system. > > Many simple operations on the Amiga take many more lines of code >than they should. For instance, openning windows, screens, or simply >attempting to get SOME control over the serial port takes mucho code >which goes very deep into the OS. This coupled with the instability >and lack of error recoverability in the OS makes for quite a few machine >crashes. The generalized I/O concept on the Amiga is too complex. To >have any control over a resource (screens, windows, serial port), you >are required to include GOBS of files, make innumerable system calls; >and although these give you full control over the resource in question, >they are generally very slow, and not fully implimented. He's actually complaining about the C language interface. Since TRIPOS/AmigaDos wasn't writtin in/for C, it's only to be expected that that interface won't be as nice as the Unix/C interface. Then again, it's nicer than the Unix/non-C interface for most languages on Unix. At least you can do non-blocking I/O in C on the Amiga. Since TRIPOS is written in/for BCPL, I suspect that the BCPL interface is *much* nicer than then C interface. Given that BCPL has an easy, natural way of using library-like facilities, the code should be smaller (the BCPL stdio equivalent should be in a library). Commodore should release the BCPL compiler so that people who want to do systems work can use it. I haven't been fighting the Amiga long enough to really comment on the C/AmigaDOS interface. I will note that the problem with the include files appears to be something broken in the C compiler. A program that uses nothing but the things in intuition.h has to have other things included to work. On the other hand, the following things are "problems" with the OS proper. These, I'll comment on seperately. > Calls like Open, Close, Rename, Delete file, etc... should be syscalls. > Ports, Device driver calls, and specific device I/O calls should NOT. > They should have been implimented through Open. Now you know why UNIX > is based on "The File Descriptor"; you've screwed yourself by not > taking that into consideration. Nope, TRIPOS is built around processes, not files. This is actually *better* than using files, as you get IPC, remote file systems, and other things that people have been kluding into Unix for the last five years for free. In fact, they were in the original PDP-11 TRIPOS. > The multi-tasking was done all wrong. Not only are > tasks defined fuzzily (and this goes along with > the signal structure), but the OS does not have the > ability to kill a task and release it's resources. > Additionaly, most of the devices should NOT have been > done as tasks. The inability to kill a task is a real problem. Tasks being fuzzy is a minor problem, related to the way pieces of processes interact. It could have been done better (witness OS/9). The device drivers *most definitely* should have been done as tasks. Since you don't have files, but tasks, there really isn't any other way to do them. And the win from making them tasks is enormous - dynamic system reconfiguration, remote device access, etc. > The filesystem (basis for quite a lot), is a good example. The >lack of IOCTL()s is very apparent. It looks as though the generalized >Port() replaces that elegant call. IOCTL - you mean that BSD-specific system call that takes arguments that change meaning with different devices? Not exactly elegant. Of course, you can't be sure that something like ioctl (only better, one would hope) exists in the interface for the systems language for TRIPOS (BCPL). >There is no truncate() (or did I >miss something??), nor is there an easy way to pass file structures >around. You truncate files just like you do on all Eunices except 4.[23]BSD. And of course, you don't want to pass file structures around, you wou want to nt to pass ports around. >and the standard input/output devices are the exception rather than >the rule. Huh? Most eunices don't have /dev/stdin or /dev/stdout, either. Or do you mean the ability to redirect stdin and stdout? That's a problem with the user interface, *not* the OS. >In my opinion, the CLI should have been more >like CSH, with the base standard I/O and execute functions built into >the OS rather than the CLI. CLI does have problems. I'd prefer ksh myself, but tastes differ. At least it isn't tied into the OS, like so many systems are wont to do. > Having easily changeable devices is nice, and you could >theoretically have your own RAM: device, but they would have best >been placed in the kernal rather than as separate processes. But then you couldn't even theoretically write your own - at least not without being able to relink the kernel. Nor could you put it on a seperate TRIPOS system over a high-speed link. >The >Amiga OS is NOT a real-time operating system. (I'm sorry, it just >isn't). I had one process running continuously, doing lots of >system calls, and a seek on the disk took... well, to put it bluntly, >it didn't happen until I killed the process. So? Aren't many multi-tasking OS's that run on micro's that *are*. 'Bout the only one I can think of is OS/9, and that's because someone worked real hard to make it one. Of course, your example makes it seem like you mean TRIPOS isn't multi-tasking, which is false. > For those of you who have knowlege of the 4.2BSD kernal, or >another UNIX like kernal, you would appreciate what has been >accomplished. The basic idea is 'multi tasking user proceses, >single tasking kernal', with everything interrupt or timer driven. > > That is the way I would have liked to see the Amiga kernal, but >Alas, it was not to be. And if they'd done that, AmigaDOS would have looked like 4.3: two large, ugly, monolithic monitors with lots of screwy interactions, both internally and with each other. As it is, you should have a collection of processes that communicate over clean interfaces, and little or no unexpected interactions. The monolithic monitor vs. communicating processes for the kernel is a religious issue on uniprocessor systems. Of course, since I have the "right" religion, I *do* appreciate what has been accomplished with TRIPOS :-). >--Going back to the filesystem-- > I realize there is a comparable Wait() call for the Amiga, but it >isn't generalized AT ALL. SELECT() is. You select on file descriptors, >period. with Wait(), you have to dig into the OS. I think you're once again tripping over ports vs. file descriptors. From what I recall (manuals not handy), you select on *ports*. Since these fill the place of Unix file selectors (except better), this is correct. > The ':' base (in addition to file path's) are a nice combination, >but the directories should have implimented '.' and '..'. Additionaly, >the directory entries are way too large. I tend to guess that almost >no thought was given to them... tell me, a COMMENT entry??? say what? Much of the niceness associated with the ':' base comes from having a forest instead of a tree. I still haven't decided if the convenience of being able to say ':' to get to root of the current device outwieghs having yet another magic character in filenames. Also (once again, unless I'm mistaken), those aren't *directory* entries, they are file headers. I haven't delved to deeply into them, but I suspect that I can find usefull things to do with the COMMENT entry. Think of it like the user bits in the CP/M dir structure. > Of course, the HARDWARE is fantastic, and in fact the one major >reason I bought my Amiga. The graphics support routines are excellent >too. However, they are not generalized enough at the programmer's end, >and check almost nothing about the validity of the data they are >processing. I get the feeling that who-ever designed the Amiga OS >didn't have much experience with multi-tasking or High Level languages. I get the feeling that you're wrong. I get the feeling that whoever did the C interface to everything didn't etc. Then again, C is a high-level PDP-11/Unix assembler, so that's not unexpected. > But the Amiga people are to good to have created some of the >things I have seen. What happened??? By the look of it, somebody >but the bolt on the entire system... not allowing any major design >changes after the first prototype was got working (and I'm talking >internal prototype's... with release still years away). Could somebody >shed some light on this? Since AmigaDos is TRIPOS underneath, it dates back to *at least* '79, and I think it actually dates back to the early '70s (I couldn't find the paper I *wanted* on TRIPOS). Most of your complaints are actually with TRIPOS, not AmigaDos (of course, I still haven't figured out what Amiga changed in TRIPOS), which, like Unix, came out of a research environment. I suspect that it went through as much development as early Unix, and the developers were probably quite happy with it. Me, I'm glad to see TRIPOS out in the real world. Maybe we *won't* be stuck with Unix on micros through the '90s. > The concept of libraries is not new. My complaint on their >usage on the Amiga is simple: The intuition library should not be >a library. The graphics library should not be a library. They should >have been system calls. The programmer should not have to OpenLibrary() >them, period. You're right, libraries aren't new. They predate Unix. On the other hand, you couldn't be more wrong about wanting them in the library. Unless your operating system is so primitive as to *not* have something like libraries (shared library code, that is), the *only* reason to put something in as a set of kernel calls instead of a library is because it's got to be in place for the system to run anyway. You're right that a programmer shouldn't have to OpenLibrary() things. The problem there is with C (maybe just the Lattice implementation), not TRIPOS. If C supported dynamic linking in a reasonable way, this problem would go away. > There are way too many programmer-"required to know about and >use" structures. The system calls should have been implimented on a >much higher level. You're now facing the problem of wanting either high-level semantics, or lots of control. For instance, consider the problem of getting a raw interface to the console. On AmigaDos, you can do it with the open(), no pain involved. On Unix, you have to "know about and use" magic structures (whose name depends on which Unix you got). On the other hand, Unix gives you more control than the AmigaDos Open. Me, I don't find dealing with windows on AmigaDos any worse than dealing with sockets on Unix - actually a little nicer, because I have fewer structures to fool with. > Solutions, anybody? I think I'm going to re-write the OS. > > -Matt Unless you're going to redo the whole package (intuition and graphics library), I wouldn't bother. In either case, I'd wait to see what the OS/9 port to the Amiga looks like. Since OS/9 combines the best features of TRIPOS and Unix, it could be a real winner. Last random comment: Someone was considering hacking up a version of libraries that were executeable, ala OS/9. As they said, this is *far* better than the ram: device. Even better would be to make use of the track-at-a-time disk driver, and tweak the disk device to grab as much buffer space as it can get to use a a LRU track cache. It would have to catch memory request to free the stuff as needed, of course. <mike
grr@cbm.UUCP (George Robbins) (01/23/86)
> My dream of the Amiga OS: (Definately Berkeley UNIX Biased) > (A) UNIX like filesystem > (B) Screens, Windows implimented w/ /dev/ device drivers > (C) I like the extended file-name idea (con:0/0...), put it in > (D) IOCTL'S > > -Matt Matt, could you ease your tone a little? AmigaDos is not itended to be unix. It is based on a model where relatively well behaved processes cooperate to accomplish desired tasks. I have heard second hand that these concepts are expressed in the literature for the 'Thoth' operating system from the U of Waterloo. I am a self confessed unix hacker, but have worked with over a dozen assorted operating systems and have found things to love and hate in each. Contemporary versions of unix, ie System V and BSD4.2 require at least of 1MB of memory and 20-40MB of disk to do anything useful... The ATT 7300 is a lot along thing lines of what you describe, but most unix people can't stand the thing. It's slow, and half the standard commands have been made optional (read: pay more) just to get it to fit on a 20MB disk. Amiga is listening, but I think they will hear more of what you say, if you present your comments in a more positive way, and skip the my (brand)car doesn't drive like a Lambourghini diatribes. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbm!grr but no way officially representing arpa: cbm!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
steve@wlbr.UUCP (Steve Childress) (01/23/86)
In article <142@atux01.UUCP>, perry@atux01.UUCP (P. Kivolowitz) writes: > Matt Dillion thinks AmigaDos is ``total shit'' and believes that Unix > is the god which all o.s. must emulate. Basing his opinions on the that > he professes to be an expert kernel hacker he thinks all should be thrown > out (except for a few graphics routines) and we should start again. > > Perry S. Kivolowitz I agree wholeheartedly with Perry. I have struggled with CP/M-80, Apple's "DOS" (==cassette tape replacement), MAC's horrid ROM & Finder, and MS-DOg, as well as Sys III and V. For small computers, Amiga's work is innovative and reflects a general high degree of expertise and great expectations. I think most of us agree that Matt's statement is at the least far too extreme and unquestionably a a valueless, reprehensible example of an OPERATING SYSTEM ZEALOT. I'd like to commend the Commodore-Amiga designers and the support people on the phones for their professionalism. Steve Childress
cc1@ucla-cs.UUCP (01/25/86)
Ok, its time we asked one question: What are the goals of an OS? Definition: Operating system: An OS is a collection of routines designed to make use of a computer's resources. corralary: An excellent operating system is one that makes excellent use of a system's rescorces. If a system has the hardware for multi-taksing, the system should be able to multi-task. The amiga operating system. This is 256K of kickstart, plus 100K of used RAM. Thats over 300K (And we complained that Atari was 200K?). The operating system's job is to manage the computer's resorces. In particular, all programs should be forced to use the operating system. That means that the operating system must be able to use all the hardware's features. So, if I add new hardware, I need to be able to change the operating system (this is the ideal case, not the amiga specific case). In a multitasking system, no one process should be able to destroy another process. Given that the amiga has no write-protection, this is hard :-). But the operating system should not make it easy for a program. Now then, are there any flames yet? Some might not like that an o/s will let you do anything, but it is a must at some point, even if it is an ioctl() call that only root can do. GIVEN: The amiga's operating system does not check its input for accuracy The amiga's operating system kills all processes (reboots) when one process blows it The amiga's operating system does not allow full access to the system's hardware (ex: The hardware includes a disk controller which can do things like writing tracks (FORMATTING) reading tracks, reading sector id's, reading single sectors, etc. All a user can do is read/write sectors a track at a time) (If I'm wrong, my appologies, but this is the impression I got from the net; I have yet to see any real docs on this particular example) CONCLUSION: The amiga's operating system is not ideal The amiga's operating system is not sutable for use in a hostile environment The amiga's operating system is not usable unless your programs are perfect. Note that by putting another layer between the o/s and the user program, input checking can be done. Since this would probably require knowledge of o/s specific data structures, this should be part of the o/s. Now for the opinions... Now, what the blazes is an o/s designed for an obsolete machine with an obsolete language and an obsolete interface standard (programs make sure the args are correct) doing on a very much NON-obsolete peice of hardware? A well thought out interface should be language independent. C or BCPL should make no difference. A well thought out interface should be orthogonal. If you draw on the screen by saying 'wp=openwindow(); draw(wp, circle, x,y,r); close(wp);', then you should be able to put a circle on the printer by saying 'wp=openprinter(); draw(wp, circle, x,y,r); close(wp)'. Now, if you make a routine open() which checks the arg given and calls openwindow or openprinter, the same code works for both. This is called device independence; the output is independent of device used. Michael Gersten Disclaimer: The opionions here are not those of the computer club nor Ucla. They may not even be correct.
rb@ccivax (01/25/86)
> Matt Dillion thinks AmigaDos is ``total shit'' and believes that Unix > is the god which all o.s. must emulate. > > Well, Matt, I don't know if you are a Unix expert and, in fact, your exp- > ertise in operating system X doesn't really bear upon the argument at hand. > are too restrictive (read that narrow minded). The answer to statements > like ``Unix is great because...and AmigaDos is shit because...'' are > senseless and without worth. The two operating systems address different > needs. > > Maybe you are a UNIX expert, Matt, but you definately are not an AmigaDos > expert. > > Perry S. Kivolowitz Matt's article was actually quite useful and valuable. I believe his primary point was that AmigaDos is not what he considers a "Programmer Friendly" operating system. This is a very legitimate concern, because it is very hard to get a lot of applications software written for a system which requires "wizard level knowledge" of the interface. Even more important is the cost of maintaining applications for such a system. A simple unix application may require say, 8 lines of code to say "hello world". An operating system that requires 10 includes, 200 lines, and 60 parameters, reguardless of how they are structured, to open a file, and print a string to it, will cost more to maintain than in an operating system that requires six lines like: main() { char *message="hello world"; fd=open("window1",1); write(fd,message,sizeof(message)); } Of course, this is old Version 7, and even 4.2 has gotten more complicated, but still, this is a lot simpler than the "Hello world" program I saw when this board first started. Just so you don't put me in the "UNIX cheerleaders camp", there are features that MS-Dos, GEM and OS-9 have, that Unix doesn't. And since I don't know any more about Intuition than from the sources posted on this net I would like to know how it stacks up. Like: The ability to add new DEVICE DRIVERS to a running system. With Unix, you have to re-link the entire operating system kernal to add a new type of device. You can mount any number of iterations of that device type via the mount command but you can't mount a new device. Intuition? The ability to share code between applications via 'trap vectors'. Unix lets you share executables but if two routines call printf you get two copies of the full floating point library tromping around both disk and ram. OS-9 lets you share "modules" like the floating point library, graphics libraries, and the like (they are mounted like drivers). What about Intuition? Only what you need is in core. Unix has drivers for things that haven't even been invented yet just to take up kernal space. Outside of the file manager, you only mount what you really need. What about intuition? Of course, if Intuition is too complicated, Commodore may go the same way North Star went with the Horizon. North Star's dos was so complicated, you had to directly manipulate the directory to add a new file, allocate enough space when you created it, and then you could think about opening it. Eventually, they wrote a bios for CP/M and let nature take it's course. Of course they may try to go the way of Ohio Scientific, who clung to their OS to the very end, right down to their async disk format. I guess they still exist on paper somewhere.
dillon@ucbvax.BERKELEY.EDU (Matt Dillon) (01/28/86)
Yes, well, with UNIX, you DO have to re-link the kernal to get new device driver's. Why? (A) The device driver's are not process (B) process or not, it would be rather a mess adding driver's to a running system due to the VM, and the fact that it would have to be a dynamic allocation. However, for a small non-MMU/VM system like the Amiga, device driver's can be added, deleted, etc.... even if they WERE NOT processes. I didn't say that the OS should have been UNIX, just that in my opinion a more UNIX-like OS would be an improvement over the current OS. Perry S. Kivolowitz is absolutely correct in his assessment of my concerns. Although the Amiga's OS may work well for the system's programmers, writing useful applications are rather difficult. However, I do see a partial solution to the problem. Hide the OS. Hide the OS? Make yourself a library with such things as chdir(), directory search routines, generic open/close (even to the point of adding non-blocking I/O, if possible, and select, if possible) which handle serial, parallel, disk and screen devices. You could also rewrite the C startup and exit routines to open/close/deallocate everything when you leave. But there are problems which cannot be hidden: (A) Slow loader... so slow that having lc1 in the ram disk doesn't significantly reduce load time. (B) Badly put together time-slicing (especially w/ disk seeks) (C) SSLOW linker... no random libraries AT ALL (D) The Disk device make no attempt to optimize disk write's or read's by sorting requests by track. Neither does it process incomming requests properly. If you executed one program, then executed another while the first was loading, the disk reads a sector from the first, seeks to the second, reads a sector, seeks to the first, etc... Thus it takes nearly 20 times as long than if you loaded the to programs in sequence. THIS IS A MAJOR FAILING! ------------- There was a discussion a while back on OS9, where it was boasted the TEXT portion of an executable (i.e. the code), was sharable when several of the same program was running. The only way I can see this happenning is: (A) An MMU or MAP hardware (B) Some register, say A5, containing the 'base' of static data, and all static references made by adding this base to the offset and doing an indirection. It occur's to me, that (B), the only possible choice for the Amiga, would slow down static fetches quite a bit. Currently, all static fetches are made through the absolute address mode. It is interesting to note that static fetches take much longer than stack fetches: Absolute Fetch long :12 clock cycles Rel. Stack fetch :8 clock cycles It also occur's to me that method (B) above would be faster than an absolute (static) fetch for the first 32K. The disadvantage, of course, is that beyond 32K you cannot use the d(An) addressing mode, and must resort to two instructions, in which case the fetch would take much longer than 12 cycles. (NOTE: 4 cycles/memory fetch) I also noticed that lattice doesn't seem to do simple optimizations like OR's to memory (i.e. it moves to d0, then Or's, then moves back).. or am I wrong? ------------ oh yah... George Robbins from CBM made a comment that UNIX's require about 1Meg of memory and at least 20-40 Meg HD's. I agree (though I prefer at least 2 Meg and 100Meg HD). Consider that in a very short time, say a year or two, 100 Meg HD's and 8 Meg Ram will be available at the same cost as 20Meg HD + 640K ram is today. -Matt
jimomura@lsuc.UUCP (Jim Omura) (01/29/86)
Mike Gerstein says that all programs must be forced to use the OS.
I take it you mean use the OS to do everything every time. Why?
Cheers! -- Jim O.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880bruceb@amiga.UUCP (Bruce Barrett) (01/30/86)
In article <357@ccivax.UUCP> rb@ccivax writes: (edited) >... A simple unix application may require say, 8 lines of code to say >"hello world". An operating system that requires 10 includes, 200 lines, >and 60 parameters, ... will cost more to maintain than in an operating >system that requires six lines like: > >main() >{ > char *message="hello world"; > fd=open("window1",1); ?? where is fd defined ?? > write(fd,message,sizeof(message)); >} > Ok, how about a system that takes 4 lines and 1 parameter?: main() { printf("Hello World"); } When compiled and linked using the "makesimple" execute file shipped with V1.1 of the development system (V3.03 of Lattice C) we can do this in 4 lines. Under the CLI this code prints "Hello world" in the current window, under workbench it opens a window for the output. You want to define the size and shape of the window to try: #include "stdio.h" main() { FILE *fd; fd = fopen("CON:10/10/300/150/Title of window", "w+"); fprintf(fd,"Hello World\n"); Delay(150); /* optional, so you can see output */ fclose (fd); /* optional, but good practice */ } > The ability to add new DEVICE DRIVERS to a running system... You can add device drivers without changing any of the kernel or kickstart code. >The ability to share code between applications via 'trap vectors'. Unix >lets you share executables but if two routines call printf you get two >copies of the full floating point library tromping around both disk and >ram. OS-9 lets you share "modules" like the floating point library, >graphics libraries, and the like (they are mounted like drivers). >What about Intuition? We support shared devices and libraries. At the moment the linked floating point support, printf, ... is not shared. Amiga DOS, Intuition, graphics, speech, audio, serial and parallel devices and libraries (to name a few) are shared. You can write your own libraries and devices which can be shared. >Only what you need is in core. Unix has drivers for things that haven't >even been invented yet just to take up kernal space. Outside of the >file manager, you only mount what you really need. What about intuition? Much of what you need (or don't) is in "ROM". "loadable" devices and libraries which you are not using (including: serial, parallel, printer, speech, and any custom devices and libraries) are loaded and removed on an "as needed" basis. Hope this answers some of your questions. As you can see we do things differently than Unix. Not necessarily better or worse. Designs and implimations are compromises and not always technically driven. Bruce Barrett, Commodore-Amiga, Inc.
drforsey@watcgl.UUCP (Dave Forsey) (01/30/86)
>AmigaDos is not itended to be unix. It is based on a model where relatively >well behaved processes cooperate to accomplish desired tasks. I have heard >second hand that these concepts are expressed in the literature for the 'Thoth' >operating system from the U of Waterloo. > Being the last person to maintain a Thoth system at the University of Waterloo (on a Honeywell Level 6 no less) and now involved with the step-daughter (son?) of Thoth called Harmony, I would be very interested if any Amiga developers could elaborate on the message passing structure of Intuition/AmigaDos. - Does it use blocking Sends and Receives with non-blocking Reply? - Are the messages fixed or variable length? If they are fixed is there any provision for passing longer messages? - What is the timing for a Send/Receive/Reply for a 8-byte message? - Does Intuition use the concept of "Administrators" (tasks that are continually awaiting messages requesting services)? - Thoth had the concept of "teams", groups of tasks which can share memory, do teams exist or are all tasks considered co-resident in memory? - What is the software interface to the interrupt level of the processor? (Note that "task" is used instead of "process", this is because Harmony is a multi-processor OS, and the separate nomenclature is less confusing). Dave Forsey Computer Graphics Laboratory, University of Waterloo, Waterloo, Ontario, Canada.
mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU (01/31/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> Matt Dillon once again savages AmigaDOS for not being Unix, among other things. To wit: (C) SSLOW linker... no random libraries AT ALL The fix is easy - use a different compiler, with a faster linker. No need to fool with the OS at all (not really an OS complaint). (A) Slow loader... so slow that having lc1 in the ram disk doesn't significantly reduce load time. I haven't noticed any serious problems loading files compared to say, a VAX running Unix. A little bit slower, but it's got floppies instead of a hard disk, and it's got to relocate stuff on the fly (no MMU - the Amigas one major failing). There was a discussion a while back on OS9, where it was boasted the TEXT portion of an executable (i.e. the code), was sharable when several of the same program was running. The only way I can see this happenning is: (A) An MMU or MAP hardware (B) Some register, say A5, containing the 'base' of static data and all static references made by adding this base to the offset and doing an indirection. And the correct answer (for OS/9) is: (C) All programs are required to be relocatable (level I and II, anyway). And what you get is actually better than Unix-like shared text. OS/9 has the ability to share the code for a library between several *different* programs running simulatenously. Multics had this, and it's one of the things that people are *still* trying to put into most Eunices. Of course, AmigaDOS has this same spiffy feature (so do most modern OS's, though), and it uses: (D) Load-time relocation. Slows down the load a little, but if done right (like, put the I/O library in one of the shared libraries), you should get back more in saved I/O after the first load than you spend relocating things. Oh, BTW, all getting Unix-like shared text requires is to have three seperate segments: text, data and stack. The only addressing mode you lose in getting shared text is pc relative. Each process gets it's own stack. I also noticed that lattice doesn't seem to do simple optimizations like OR's to memory (i.e. it moves to d0, then Or's, then moves back).. or am I wrong? I've been told that Lattice C is a recursive descent compiler. Anybody silly enough to write a recursive descent compiler for something like the Amiga (or most anything else....) is silly enough to miss OR's to memory. If this rumor is wrong, *please* let me know. oh yah... George Robbins from CBM made a comment that UNIX's require about 1Meg of memory and at least 20-40 Meg HD's. I agree (though I prefer at least 2 Meg and 100Meg HD). Consider that in a very short time, say a year or two, 100 Meg HD's and 8 Meg Ram will be available at the same cost as 20Meg HD + 640K ram is today. True, but a PIG is still a PIG. I'd rather use all those juicy resources making my life easier than providing for a piggy OS. Mat's proposed solution to some of the OS (?) problems: Hide the OS. Hide the OS? Make yourself a library with such things In other words, build a better C<->AmigaDOS interface. One of the most important things to do would be get the library allocation back into load-time, where you don't have to write funny code to deal with it. Access to the global vector would be nice (shrinking code a *lot*), also. But any attempts to squeeze a langauge onto an OS designed with another language at it's heart is going to require either a lot of work, or wind up being ugly (witness LISP, Pascal and FORTRAN on Unix). Final comment. I finally got my AmigaDOS manuals, and got a look at what's going on inside that file system. My hat's off to whoever designed it. It's simpler than the Unix file system, much more robust, and except for some special cases, should be faster (the important special case is globs). The most imporant thing to notice is ~1/2 the disk access to turn a pathname into a file*. It's just to bad that globs are so heavily used by the workbench. <mike * Except for 4.3BSD, which put caching into pathname->inode translation. Since this got back about 20% of the CPU, you can decide for yourself how important the AmigaDOS 50% decrease in disk accesses is going to be.
mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU (02/01/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> rb@ccivax says: >A simple unix application may require say, 8 lines of code to say >"hello world". An operating system that requires 10 includes, 200 lines, >and 60 parameters, reguardless of how they are structured, to open a >file, and print a string to it, will cost more to maintain than in an >operating system that requires six lines like: > >main() >{ > char *message="hello world"; > fd=open("window1",1); > write(fd,message,sizeof(message)); >} Ok, here, for your edification, is a simple program that opens a window, prints "hello world", and then waits for you to hit return and exits. I used the text above with the following changes: 1) Declared fd. 2) Declare message as an array, instead of a pointer. That way, sizeof will report the length of the string, instead of the length of the pointer. 3) Made message static, so that it could be initialized. 4) Changed the open call to use AmigaDOS names & numbers. 5) Added a read so the window didn't disappear. char message[]="hello world"; main() { int fd ; fd=open("CON:10/10/200/100/Window1",1006); write(fd,message,sizeof(message)); read(fd,message,sizeof(message)); } Note that it takes 8 lines, 0 includes, and exactly as many parameters as the Unix version above. Also note that this is *not* code to emulate when writing C. The second flag to open should be picked up from an include file, the open and write calls should have their return values checked, and fd should be declared as a type from an include file somewhere. It does, however, resemble much of the code to be found in Unix utilities. Now, about Unix device drivers: > The ability to add new DEVICE DRIVERS to a running system. With Unix, >you have to re-link the entire operating system kernal to add a new type >of device. You can mount any number of iterations of that device type >via the mount command but you can't mount a new device. Intuition? This reminds me of dBase-II, being that which bilge pumps suck. Each Unix device type has a driver, and those drivers have some data elements that are allocated at compile time, one per iteration of the device. Hence, the maximum number of copies of the device that can be added is fixed at compile time for the driver. The mount command has nothing to do with adding devices to a system. It's used to add a file system on a random-access device to the file system tree. AmigaDOS doesn't have such a beast, since it has a forest instead of a tree (this is a win). Now, on to AmigaDOS: >Only what you need is in core. Unix has drivers for things that haven't >even been invented yet just to take up kernal space. Outside of the >file manager, you only mount what you really need. What about intuition? AmigaDOS looks in a known directory for drivers, and loads them when you access the device. Unix, on the other hand, chews up the same amount of memory for each device, whether it's physically attached to the system or not (exception: some Eunices crash if a device configured in the kernel isn't on the system). I should explain what the mount() call really does, but suffice to say that mounting a file system doesn't change the amount of kernel space used one wit. >Matt's article was actually quite useful and valuable. I believe his primary >point was that AmigaDos is not what he considers a "Programmer Friendly" >operating system. This is a very legitimate concern, because it is very >hard to get a lot of applications software written for a system which >requires "wizard level knowledge" of the interface. I disagree. Applications don't appear on a machine because it is easy to write software for it; applications appear on a machine because people think there are going to be a lot of those machines. Witness the IBM-PC and MSDOS. Are you going to argue that that's a "programmer friendly" environment? On the other hand, consider Unix. Almost any non-trivial application requires "wizard level knowledge" of the interface (assuming you're writing in C - other languages can't get to that interface at all). But Unix is a primitive OS, so it has a simple interface, meaning that applications are easy to write. Oddly enough, no applications showed up on it for the first 10 or more years of it's life - because there wasn't a market for them. The people who developed Unix were working on a system for their own private use, and had no concerns other than making it easy to write programs for it. The people who developed AmigaDOS were developing an OS for a system that they were planning on selling to make money off of. There first concern shouldn't be making it programmer friendly, it should be making it *user* friendly. I think they did a good job. If you go back over Matt's complaints, you'll find that most of the accurate ones have to deal with the interface between C and the libraries it uses. This interface should be fixed in later releases. For the early releases, worrying about it instead of the user interface is silly; what percentage of Amiga's are going to be sold to programmers if it's going to succeed? To summarize: yes, the Intuition interface is hard to program. However, if you stay inside the CLI interface, it's about the same as Unix v7. On the other hand, Intuition is user friendly, and AmigaDOS itself is easier for naive users than any "standard" Unix shell (csh, sh, or ksh). I've been saying for over 5 years that Unix should be trashed in favor of something else. AmigaDOS provides the same level of expert-friendlyness as the Eunices that existed then. It also shows *much* more user-friendlyness for non-expert users. AmigaDOS wouldn't be a great successor for Unix. But it's adequate. <mike Celebrate, as "Unix, the OS/360 of the 80's" may not be true after all!
jimomura@lsuc.UUCP (Jim Omura) (02/01/86)
Using OS-9 on the Radio Shack Color Computer I have added device
descriptors and drivers on the fly. This is because OS-9 device drivers,
properly written are done in position independant code and are fully
relocatable modules.
Cheers! -- Jim O.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880mykes@3comvax.UUCP (Mike Schwartz) (02/01/86)
Just a quick thought: How many lines of Unix code does it take to do any of the following: 1. open a window with any of the standard Unix gadgets? 2. translate and narrate a block of text? 3. animate and move objects around on the screen? 4. birth a new cli (shell) task in it's own window? 5. any Intuition function (icons, drawers, etc.)? 6. generate fonts on the screen? The point I am trying to make is that it probably takes as much code to implement the Amiga OS as it does Unix. Unix has had many years and many programmers to develop it to the point of refinement (that's the best I can say for it, text only is boring to me). OS-9 may have been a better choice than AmigaDos (or TRIPOS or whatever), but it was not chosen and it's too bad. If OS-9 ever makes it to the Amiga, it better work with all the programs everyone has been writing, or I (and maybe a few others) won't go near it. I like intuition a lot, and I am glad that Amiga chose to give us primitive routines to build libraries around instead of some real high- level limited-function interface. Have any of you Unix freaks ever seen the AT&T Unix PC? It seems to me that it is all you have been asking for. I think it is remarkably like the Amiga, with it's windows and C-Shells running in them. And it uses the mouse, and has hi-res screen and has a few gadgets, etc. It also runs UNIX native, connects to mainframes well, runs all the Unix programs you have become comfortable with over the years. It has a 68000 and comes with a hard disk. It is VERY IMPRESSIVE to me, to say the least, although I still like the Amiga better because of the software.
nckary@ndsuvax.UUCP (nckary) (02/05/86)
In message <1133@caip.RUTGERS.EDU> Mike (I'll be mellow when I'm dead) Meyer writes: > I've been told that Lattice C is a recursive descent compiler. > Anybody silly enough to write a recursive descent compiler for > something like the Amiga (or most anything else....) is silly enough Please explain yourself. I have written compilers that parse top down and compilers that parse bottom up and I don't see a reason to call either technique silly. YACC has made LALR parsing very popular and I almost always use YACC because it is so convenient, but LL parsing is just as viable and in the absence of YACC it may be easier to implement. I suppose the reason that LL (recursive descent) parsing has a bad name is that in it's simplest form the parser selects productions in a pre- determined order and backtracks when a dead end is encountered. Recursive descent can be refined by adding a selection set for each production. The selection set permits the parser to select the correct production in any situation, so backtracking is eliminated. This sort of parser is sometimes called a Deterministic Recursive Descent Parser. The execution time for this type of parser is Big Oh of n (where n is the length of the input sentence), which is as good as it gets! Another possible drawback to LL parsing is that LL grammars can not contain left recursive rules (direct or indirect). Many programming languages are specified with grammars that are left recursive because it is both convenient and intuitive. While algorithms exist to transform left recursive grammars to non left recursive grammars the result can be considerably less intuitive. There are advantages to LL parsing if you are up to the task of writing the grammar. I personally think that error detection is easier in an LL parser. Once an LL grammar is written, the parser is trivial. I would not want to write an LALR parser without the aid of something like YACC. Maybe I'm making a mountain out of a mole hill but LALR parsers seem complex to me. A good text on this subject is "Compiler Design and Construction" by Arthur B. Pyster published by PWS Publishers (Prindle, Weber & Schmidt). The text is intended for undergraduates, it is easy to read and includes an example compiler for a PASCAL like language using a recursive descent parser. The example is coded in "structured English". The only point here is that the use of recursive descent is not automatically a reason to sneer at a compiler and may well be a reason to admire it. Since I do wish Mike a long and fruitful live, I will not ask him to become mellow :-). Dan Kary North Dakota State University Computer Science Department 300 Minard Hall P.O. Box 5075 Fargo, ND 58105 (701) 237-8171 ihnp4!dicomed!ndsuvax!nckary
rb@ccivax.UUCP (02/06/86)
In article <618@amiga.amiga.UUCP> bruceb@amiga.UUCP (Bruce Barrett) writes: >In article <357@ccivax.UUCP> rb@ccivax writes: (edited) > fd = fopen("CON:10/10/300/150/Title of window", "w+"); I like this open feature, glad you pointed it out. Can you also do something like: box(TopLeftCorner,BottomRightCorner,fd) ; maybe those early postings from readers who didn't know you had a graphic version of standard I/O. >> The ability to add new DEVICE DRIVERS to a running system... > You can add device drivers without changing any of the kernel or > kickstart code. Good! Can someone write a driver that is the equivelant of a pipe? >> OS-9 lets you share "modules" like the floating point library, >>graphics libraries, and the like (they are mounted like drivers). >>What about Intuition? > We support shared devices and libraries. At the moment the > linked floating point support, printf, ... is not shared. Sounds like this is more of a matter of time, rather than lack of forsight. >>Only what you need is in core. > Much of what you need (or don't) is in "ROM". "loadable" devices > and libraries which you are not using (including: serial, parallel, > printer, speech, and any custom devices and libraries) are loaded > and removed on an "as needed" basis. I assume the 'hooks' to the "ROM" are somewhere in RAM so they can be re-vectored if necessary? >Hope this answers some of your questions. As you can see we do things >differently than Unix. Not necessarily better or worse. >Bruce Barrett, Commodore-Amiga, Inc. From the looks of things, there have been some good choices made. Seems like there's the best of Mac combined with most of the best of UNIX. Hopefully, when the cheerleaders get over the initial 'contempt prior to investigation', some of the Amiga system will be incorporated into some new 'Defacto Standards'. Any plans on liscencing Intuition? About the only variable still in question is portability. Appearently Commodore-Amiga would like to corner developers into writing source which is exclusively for their machine. IBM plays that game real well. Apple seems to be less successful in their MAC line. DEC doesn't seem to worry so much about that sort of thing, they even have their own version of UNIX. How many people are using a VAX to get this? Is it running UNIX? Probably the main reason for the 'OS-9 and Unix static' is that neither Tripos nor Intuition/AmigaDos were familiar to US programmers. Seems like people get nervous when the same company does both the hardware and the software. Maybe it's the scars from the mutually exclusive characteristics of Apple/Atari/Commodore and other 6502 machines and even the TRS-80 Lines. CP/M and MS/Dos machines, though grossly inferior, were being considered the "Business Systems", while the "proprietary boxes", with graphics and even some better software were being considered "toys". Having been burned three times, I'd like to know that I can "Hedge my bet's" before I go for double or nothing. I could care less about IBM compatibility, what I would like though is an OS that would let me buy/run/sell the same application software on the Mac, Amiga, and the ST without having to spring for a three separate copies. Or at least be able to excange data between the three without having to physically connect the machines (modem, comm-lines...). There are situations where each would be desirable (We already have a Mac, but not much software, Amiga's are powerful enough to do presentation graphics, and ST's are cheap and 'good enough for photo-copy stuff') but not if they continue to 'snub' each other. I'd hate to see the 68000 lose out to the 80386, but it might if the Mac/Amiga/ST people won't play ball with each other. Has IBM announced their '386 machine yet?
aglew@ccvaxa.UUCP (02/06/86)
How many lines of UNIX code does it take to change a lightbulb? One - use an ioctl. or None - it has to be done in the kernel.
bruceb@amiga.UUCP (Bruce Barrett) (02/10/86)
In article <374@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes: >In article <618@amiga.amiga.UUCP> bruceb@amiga.UUCP (Bruce Barrett) writes: >>In article <357@ccivax.UUCP> rb@ccivax writes: (edited) >>>Only what you need is in core. >> Much of what you need (or don't) is in "ROM". "loadable" devices >> and libraries which you are not using (including: serial, parallel, >> printer, speech, and any custom devices and libraries) are loaded >> and removed on an "as needed" basis. > > I assume the 'hooks' to the "ROM" are somewhere in RAM so they > can be re-vectored if necessary? > What is in ROM are the routines necessary to load the drivers from disk. If you don't like devs:serial.device I suppose you could write your own (upwordly compatable) copy and put that in the DEVS: directory. This might create a problem later for you if Commodore-Amiga also chooses to release a new upwardly compatible version of the same driver. (Murphy says "they won't match!") --Bruce Barrett
jimomura@lsuc.UUCP (Jim Omura) (02/11/86)
In article <374@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes: >In article <618@amiga.amiga.UUCP> bruceb@amiga.UUCP (Bruce Barrett) writes: >>In article <357@ccivax.UUCP> rb@ccivax writes: (edited) > >About the only variable still in question is portability. Appearently >Commodore-Amiga would like to corner developers into writing source >which is exclusively for their machine. IBM plays that game real >well. Apple seems to be less successful in their MAC line. >DEC doesn't seem to worry so much about that sort of thing, they even >have their own version of UNIX. > >How many people are using a VAX to get this? Is it running UNIX? I'm 'here' via Unix--on a *Perkin-Elmer*! > >Probably the main reason for the 'OS-9 and Unix static' is that neither >Tripos nor Intuition/AmigaDos were familiar to US programmers. Seems >like people get nervous when the same company does both the hardware >and the software. Maybe it's the scars from the mutually exclusive >characteristics of Apple/Atari/Commodore and other 6502 machines and >even the TRS-80 Lines. CP/M and MS/Dos machines, though grossly >inferior, were being considered the "Business Systems", while the >"proprietary boxes", with graphics and even some better software >were being considered "toys". Having been burned three times, I'd like >to know that I can "Hedge my bet's" before I go for double or nothing. > >I could care less about IBM compatibility, what I would like though >is an OS that would let me buy/run/sell the same application software on >the Mac, Amiga, and the ST without having to spring for a three >separate copies. Or at least be able to excange data between the >three without having to physically connect the machines >(modem, comm-lines...). There are situations where each would be >desirable (We already have a Mac, but not much software, Amiga's >are powerful enough to do presentation graphics, and ST's are >cheap and 'good enough for photo-copy stuff') but not if they >continue to 'snub' each other. I'd hate to see the 68000 lose out >to the 80386, but it might if the Mac/Amiga/ST people won't play >ball with each other. Has IBM announced their '386 machine yet? Now we're getting to the crux of the problem. If "Intuition" is only "as good as" OS-9 or anything else, or at best can become an OS of this level, then Commodore (and Atari) have really done a disservice to the 68000 world. The *last* thing we needed was another wheel reinvented. To be excusable, I have to say that TriPOS must be shown to be *better* than OS-9. It clearly isn't. For those who don't know, the 68K world has *many* excellent OS's. The most popular before the Mac were CP/M 68K, OS-9, Uniflex and either P-code or Forth among the smaller systems. In large systems the various permutations of Unix *are* the standard. Out of the above, CP/M 68K is widely bought and rarely used. There's simply no reason to bother with it. There isn't much useful software available and the only thing you can do get around it as best you can. P-code and Forth have their followings, but the same arguments for and against these are know in all the other processor family worlds. I won't repeat them. That leaves OS-9 and Uniflex. Both OS-9 and Uniflex are powerful Unix-like OS's. Both originated in the Motorola world (both on the 6809 to be precise). At this time OS-9 has become essentially a standard for small systems based on 68K's. The idea that *only* one of either the Atari or the Amiga is going to survive is silly. I don't believe it. Both are excellent machines. Why should only 1 survive? In the mean time, you have raised the standard of another non-standard why? Haven't you, Commodore learned your lesson yet? Look at the fiasco of your non-ASCII computers from the Pet through to Plus 4? Look at the problems people had trying to use other peripherals with your IEEE-488 bus, when what they wanted was true ASCII and RS-232C. Haven't you heard their cries when new software for Apple II's or Ataris were introduce? Or were you even listening? There are times and ways to break new ground--to advance the state of the art. To be different just for the sake of being different is childishness. If you must be different just for the sake of being different, then wear your shirts backwards. That much costs no else anything. Cheers! -- Jim O. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU (02/13/86)
From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> Jim Omura (lsuc!jimomura ?) Makes a few questionable statemens: > Now we're getting to the crux of the problem. If "Intuition" is >only "as good as" OS-9 or anything else, or at best can become an >OS of this level, then Commodore (and Atari) have really done a >disservice to the 68000 world. The *last* thing we needed was >another wheel reinvented. To be excusable, I have to say that >TriPOS must be shown to be *better* than OS-9. It clearly isn't. No, but it isn't clear that OS-9 is superior to TRIPOS, either. What is clear is that OS-9 inherited at least one of Unix's fundamental flaws, whereas TRIPOS didn't. In other words, it *could* be better than OS-9, given a little development time. Actually, if you're a hacker, it already is. I can do stackable line disciplines in TRIPOS. Can I do them in OS-9? There are probably other, similar things that I haven't found yet. >At this time OS-9 has become essentially a standard for small systems based >on 68K's. Can I get OS-9 for Stride? Pinnacle? the Tandy 68K box? Compupro 68K systems? I don't think so (unless it's from second-party vendors), but TRIPOS runs on both the Stride and the Pinnacle. Anyone know if carefully-written (i.e., avoiding the windowing/graphics software) code will run on TRIPOS? Along the same lines, what kind of windowing/graphics standard exists for OS/9-68K. Don't complain about Amiga having chosen a non-US OS for their box. TRIPOS does have a following (which I was happy to find out; TRIPOS has always seemed like to nice an OS to die), it's just not as visible as OS-9, being mostly in Britian. They didn't raise a new "non-standard", they just chose one you weren't familiar with. >There are times and ways to break new ground--to advance the state of the art. You're right, and I think this is one of them. It's time to outgrow Unix and it's look-alikes. OS-9 presents lots of interesting improvements over Unix's of the early 80's (most of which are now in system V, except for the much better speed), and MicroWare is to be congratulated for helping spread the word about such things. AmigaDOS presents lots of interesting improvements over Unix's today. It *isn't* useable as a replacement for either Unix or OS-9 in many places where they are used. But it makes some good ideas visible to the world, (we're talking about them, aren't we?), and is to be applauded for doing so. <mike
jimomura@lsuc.UUCP (Jim Omura) (02/15/86)
Before I begin, thank you for your very appreciated reply. In article <1270@caip.RUTGERS.EDU> mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU writes: >From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> > >Jim Omura (lsuc!jimomura ?) Makes a few questionable statemens: > >> Now we're getting to the crux of the problem. If "Intuition" is >>only "as good as" OS-9 or anything else, or at best can become an >>OS of this level, then Commodore (and Atari) have really done a >>disservice to the 68000 world. The *last* thing we needed was >>another wheel reinvented. To be excusable, I have to say that >>TriPOS must be shown to be *better* than OS-9. It clearly isn't. > >No, but it isn't clear that OS-9 is superior to TRIPOS, either. What >is clear is that OS-9 inherited at least one of Unix's fundamental >flaws, whereas TRIPOS didn't. In other words, it *could* be better >than OS-9, given a little development time. Actually, if you're a >hacker, it already is. I can do stackable line disciplines in TRIPOS. >Can I do them in OS-9? There are probably other, similar things that I >haven't found yet. Excellent. What are they and where do they become an advantage? > >>At this time OS-9 has become essentially a standard for small systems based >>on 68K's. > >Can I get OS-9 for Stride? Pinnacle? the Tandy 68K box? Compupro 68K >systems? I don't think so (unless it's from second-party vendors), but >TRIPOS runs on both the Stride and the Pinnacle. Anyone know if >carefully-written (i.e., avoiding the windowing/graphics software) >code will run on TRIPOS? Along the same lines, what kind of >windowing/graphics standard exists for OS/9-68K. Good point. Except OS-9 is widely used around the world. HSC in particular sells it in Europe and in Japan it runs on various Fujitsu and, I think Hitachi machines. Fujitsu in particular is a company I think most people here should have heard of by now. It is one of the big 3 computer mfrs. in Japan. They make everything from personal computers to mainframes of very high capacity and power. It would not surprise me to find out that Fujitsu's 68000 OS-9 systems have outsold Stride and Pinnacle combined on a world-wide basis. Then there are the numerous single board computers based on the Mizar, Gimix and Helix 68K multi-user systems. There is a development system for the VME-10 which should be usable with similarly configured VME bus computers and of course SS-50 systems. There are other single board OS-9 systems as well. The Emerald 68K systems come to mind. As for myself, I'm waiting for the port to the Motel Cypher board to be completed. I expect to have my 68K system up by April. The last I heard, the Atari port is expected this spring. Now, as for the Amiga port, I have no idea, but J. Jones' recent posting disturbs me. It looks like the people attempting that port are in trouble, unless I misunderstood the gist of it. >Don't complain about Amiga having chosen a non-US OS for their box. >TRIPOS does have a following (which I was happy to find out; TRIPOS >has always seemed like to nice an OS to die), it's just not as visible >as OS-9, being mostly in Britian. They didn't raise a new >"non-standard", they just chose one you weren't familiar with. I read British computer magazines on a fairly regular basis. (Which Computer?, Which Micro, Your Computer, Computing Today and whatever else comes across the pond--not all issues, but a couple of each every year with a half dozen issues/yr. of a couple of them. The British seem to be able to support an amazing number of periodicals every month.) I have rarely seen mention of TRIPOS. OS-9 68K isn't all that well known in England either, but OS-9 6809 is. But then the British even prefer Flex (no, not Uniflex but the *old* Flex) to OS-9, so what can you make of popularity in England? :-) >>There are times and ways to break new ground--to advance the state of the art. > >You're right, and I think this is one of them. It's time to outgrow >Unix and it's look-alikes. OS-9 presents lots of interesting >improvements over Unix's of the early 80's (most of which are now in >system V, except for the much better speed), and MicroWare is to be >congratulated for helping spread the word about such things. AmigaDOS >presents lots of interesting improvements over Unix's today. It >*isn't* useable as a replacement for either Unix or OS-9 in many >places where they are used. But it makes some good ideas visible to >the world, (we're talking about them, aren't we?), and is to be >applauded for doing so. I'll assume this doesn't end the discussion. I expect that you *will* find more points which you feel give you and advantage. So far, I can't say that I feel your points show that TRIPOS is a system to "grow into" from OS-9. You have pointed out a feature which you feel gives it an advantage. It isn't a feature which I recognize, but even still I have my doubts whether it's all that significant (I think I know what you're talking about, but I'm not sure and if it *is* what I think it is, I can't see any advantage to it at all--not disadvantageous, just not better.) Anyway, I'll look forward to the next instalment if any. Cheers! -- Jim O. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
rb@ccivax.UUCP (rex ballard) (02/18/86)
Imagine having to gamble on a new car if GM used diesel, Ford used unleaded, Chrysler used gasahol, Honda used alcohol, Toyota used coal gas, ..... and so on for about 20 different cars, and no car could use another's gas. What kind of gas should the gas stations sell? What should the refiners produce? What investments should be made (oil wells or farm land?). This is the delemma faced by the computer industry today. Each "proprietary system" succeds or fails based on this very logic. IBM has set one standard (however obsolete), it is time for another to be set. In article <1270@caip.RUTGERS.EDU> mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU writes: >From: Mike (I'll be mellow when I'm dead) Meyer <mwm%ucbopal@BERKELEY.EDU> >>The *last* thing we needed was >>another wheel reinvented. To be excusable, I have to say that >>TriPOS must be shown to be *better* than OS-9. It clearly isn't. >No, but it isn't clear that OS-9 is superior to TRIPOS, either. >>At this time OS-9 has become essentially a standard for small systems based >>on 68K's. > >Can I get OS-9 for Stride? Pinnacle? the Tandy 68K box? Compupro 68K >systems? It is possible to get OS-9 68K for all three of these machines, in fact Level 2 (Segmented with MMU), and Level 3 (Demand Paged Virtual Memory) may also be available and are source code (and object?) code compatibile. >I don't think so (unless it's from second-party vendors), but >TRIPOS runs on both the Stride and the Pinnacle. TRIPOS is a subset of Intuition, I assume it is available or portable to any manufacturer willing to port it, or a third party? (Liscence fees?). But Intuition is not in this class, if it were, the possibility of using TRIPOS as a 68K equivelant of CP/M or MS/DOS might be worth considering. >Anyone know if >carefully-written (i.e., avoiding the windowing/graphics software) >code will run on TRIPOS? Along the same lines, what kind of >windowing/graphics standard exists for OS/9-68K. There is a VDI interface included, windows are part of the whole package. (Material from UW included announcements for full 63485 support) They also support true networking capabilities. >Don't complain about Amiga having chosen a non-US OS for their box. >TRIPOS does have a following (which I was happy to find out; TRIPOS >has always seemed like to nice an OS to die), it's just not as visible >as OS-9, being mostly in Britian. They didn't raise a new >"non-standard", they just chose one you weren't familiar with. TRIPOS may or may not be a true 'standard', but the packages which make it useful and desirable (VDI graphics, Windows, Mice...) are 'Amiga Only'. >>There are times and ways to break new ground--to advance the state of the art. >You're right, and I think this is one of them. Here, I agree, this is the time to advance the state of the art in the form of a practical "Industry Standard OS" equal or better than the "Mac Enviroment" with multi-tasking. Amiga provides these things, but at the cost of data and program market incompatibility. Personally, I wouldn't care whether it was TRIPOS, OS-9, VRTX, XINU, or Concurrent CP/M 68K, but if one of these systems becomes available, it should be adopted as quickly as possible, or ALL of the 68K machines really will be just "Toy Computers" to many businesses. Apple, Atari, and Commodore had more capabilities on their machines individually than CP/M or MS-DOS put together, but those were the "REAL COMPUTERS", while the 6502 machines were "TOYS". The big 3 can compete with graphics processors, faster CPU's, floating point co-processors, and other competitive edges all they want, and they'll get good support. Right now, you have to give these machines a frontal lobotomy to make them IBM compatible, (This makes it a "serious machine") and even then Apple has not really done that well against "Big Blue's Box" even after two years. Many companies bought VAX and other non-IBM mini-computers because UNIX made them source code compatible. Even UNIX micro's have succesfully cut into the Series 1 market, because they run UNIX. The consumer will only tolerate about 3 standards. In Audio, it's 45's LP's, and Cassettes, with 45's giving way to CD-Roms. In Video, there are really only two standards, VHS and BETA. Now imagine the market situation if Sony, JVC, Magnavox, Panasonic, and Zenith all used their own "proprietary" standards. Perhaps Commodore will see the benefits of providing this industry standard system, perhaps Micro-Ware or some as yet unknown "wizard" will perform this great service. When it happens, I hope that we are all willing to accept the "trade-offs" and adopt it. If it does not happen, I hope the "industry wide crash" won't be too severe.
hollombe@ttidcc.UUCP (The Polymath) (02/19/86)
In article <408@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes: >Imagine having to gamble on a new car if GM used diesel, Ford used >unleaded, Chrysler used gasahol, Honda used alcohol, Toyota used coal >gas, ..... and so on for about 20 different cars, and no car could use >another's gas. > >What kind of gas should the gas stations sell? What should the refiners >produce? What investments should be made (oil wells or farm land?). >This is the delemma faced by the computer industry today. Each "proprietary >system" succeds or fails based on this very logic. Wrong analogy, I think. This would be more appropriate if each computer had different input power requirements (60 vs 50 hz. vs DC. 110, 120, 220, 240, etc. volts) although that's more easily compensated for than differing chemical fuels. Closer to the mark would be radically differing steering and control mechanisms. Throttle on the steering column, rear-wheel steering, that sort of thing. Does it really matter which is better? Commodore is obviously committed to their operating system and isn't about to switch to OS-9 or UNIX at this point. If there's enough demand third party vendors will step in to fill the gap and all the people who don't like Intuition will get their own preference. Meanwhile, this whole debate has little to do with the Amiga per se and probably belongs in another group. Enough, already. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ The Polymath (aka: Jerry Hollombe) Citicorp(+)TTI 3100 Ocean Park Blvd. Geniuses are people so lazy they Santa Monica, CA 90405 do everything right the first time. (213) 450-9111, ext. 2483 {philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe