DEC.BANKS@MARLBORO.DEC.COM (01/21/86)
From: Dawn Banks <DEC.BANKS@MARLBORO.DEC.COM> Some comments on Amiga DOS (and related software) prompted by earlier mail asking for opinions. Maybe a bit long winded, but please don't construe it as a flame, as it's not intended as one. Mostly, this is my [boring] contribution to the ongoing dialog on what we'd like to see in Amiga DOS. First, compared to OS/9 running on a Trash Color, the multitasking on Amiga DOS is a lose. Not that it isn't useful, as I probably make more use of the multitasking than the Amiga folks probably intended me to. Part of this problem stems from the fact that our 512K Amiga system is basically a memory starved machine; a comment I wouldn't have thought I'd be making a few months ago, coming from a 48K Atari 800 and a 64K CoCo. For instance, the linker is slow. Given multitasking, that doesn't bother me too much, because I can go edit something else (or print something, or play something) while the link is running, right? Well, not quite, because the linker is also a memory pig when it links C programs. The lack of speed, and the abuse of memory are particularly odd, because if you read through the documentation, you'll find that it doesn't really DO that much. The net result is that if I have anything significant running while the linker's doing its thing, or if I have anything significant in the RAM: device, we run out of memory. So, I have to sit there, watching the linker polish a floppy for a couple of minutes, emulating a non-multitasked machine. I think ALINK is reading all of the libraries into memory, which it doesn't really need to do. I'm gonna have to play with this one some more. The load file format precludes any reasonable possibility of swapping or shuffling. Maybe to be more specific, unlike OS/9 running on a 6809, load files aren't assumed to be position independent code. This means that once the Amiga DOS load file has been put into memory, it's pretty well "stapled" down to where it's been loaded with all the absolute references fixed up to reflect the location where the module was loaded. This is not really bad in and of itself, but it would be nice to swap tasks given ALINK's thirst for memory. OS/9 gives you "sharable" segments, by which two people using the same segment are really using the same segment. Not only does it allow you to save memory while running multiple copies of something (most notably, the SHELL, of which there always seem to be at least two invocations), but it also allows you to do cute things. The best one is permanently incrementing the use count on the segment so that it never gets purged from memory. Then, when you run that program, it just looks in the task header to see how much impure storage it wants, allocates the memory, bumps the shared segment's use count, and you're all set. Don't have to ding the disk a bit. Later, if you want the memory back, you can UNLINK the module, which just decrements the use count, so that it'll get thrown out when everyone's done with it. Amiga DOS does this completely in reverse: If you want to run something a bunch of times, and don't want to wait around for the disk read (or can't wait around, 'cause the disk isn't mounted), you have to copy the task into RAM:, and run it from there. This is the most insidious form of memory waste I've seen, in that once you run it from RAM:, you're carrying around TWO copies in memory, instead of just one (the one you're running, and the one in RAM:). I've been playing around with the idea of implementing programs as loadable libraries, with "stub" programs that are run in response to a command. This stub would open the library, and call the appropriate entry point with all the command line arguments. Thus, you'd have code sharability and some primitive form of caching in core copies of commands. The only bad part of this is keeping all the stubs in C: or RAM:. Would probably have to write all the stubs in assembler (a feature to me), because most Lattice C programs seem to end up with load files bigger than most of the commands in C: combined. No pipes??!??!?! Where are the &^*( pipes? Why can't I stop a runaway task, and why do you have to go out of your way to make your program stoppable when you write it rather than the other way around? How about a "BREAK 2 -dammit"? Also, from disassembler reading, it's very clear that most of the commands in C: use some sort of CLI library, or at least a set of internal entry points to do nearly everything from typing things to scanning the command line arguments (FOO/K,BAR/A style). Which prompts two questions: (1) does anyone from Amiga want to impart some knowledge of how to use these entry points, so we can all make commands that look just like normal Amiga DOS commands, and are as SMALL as normal Amiga DOS commands (I know, fat chance), and (2), what is it that these CLI commands do to make the command name known to the STATUS command? I've been through all the data structures with WACK, and I can't find any name string that isn't filled in for anything else. On to the file system: It's cute for a toy computer, but is this a toy computer? In particular, Amiga doesn't seem to be making any friends with the hashed index scheme. It's easy enough to understand why such an approach was taken, as it solves a few nasty problems. For instance, with the <put the filename and index block pointer into the directory entry> scheme, you find that you either (A) preallocate a maximum directory size when the directory is created, and then impose arbitrary limits to the number of files in the directory and at the same time waste precious disk space on preallocated directories with only one or two files in them or (B) you get into the ugly mess of learning how to dynamically expand and compress directories when they get filled up; a problem which gets exponentially ugly if you've got more than one task running. Still the problems aren't insurmountable, and I feel that someone's traded programmer convenience (Commodore corp's, that is) for human interface and long term usability. All comments about filename wildcarding aside, this is the first operating system which I have been completely unable to induce to place files in a directory in the order I'd like them, and that's by design. It's very nice for files to be in a directory in alphabetic order, if only for distribution/archive purposes. If not alphabetic, in order of creation date is almost as nice. As it is, I can do neither, with the result that I'm completely unable to find anything in a directory containing more than 20 or so files, unless I use the DIR command, which doesn't give me creation dates or file sizes. On the plus side, I really appreciate that Amiga DOS both remembers disks, and allows me to specify the name of an as-yet unmounted volume as part of a file specification. This allows you to run applications that access more data than you can have mounted all at once, which in itself is a resounding win. It's just a shame that Lattice C executable files fill a disk so fast that this is almost the rule rather than the exception. Overall, coming from 8 bit computers with <64K available memory and 180K byte SSDD floppies, I'm pretty surprised at how often I run out of memory and disk space on our 512K system with 2 880K floppies. All of which leaves me with a burning desire to either write my own operating system (which would be loads of fun if I really had the time on my hands) or to pitch Amiga DOS, and go in search of OS/9 for the Amiga. The only problem with both of these solutions is that we're fairly guaranteed that the majority of canned software coming down the road is going to be written for whatever Commodore supports, and not OS/9 or homegrown. Don't get me wrong: Amiga DOS is a quantum leap above most of what's running on microcomputers these days. If I'd never had the opportunity to work with much nicer operating systems on larger machines, I might not be making these complaints. But, what really hurts is that I've seen OS/9 on the ($300) TRS Color Computer, which in most respects is far and away a superior multitasking system to Amiga DOS. Only trouble is, that there's no software written for it (to speak of). D. Banks. --------
mykes@3comvax.UUCP (Mike Schwartz) (01/22/86)
For those of you using Lattice 'C' out there, I made the followig observation
today. The following function compiles into 100 bytes of code on the
IBM PC (you can bet the 68000 requires 150 bytes, based upon the size
of LC1 and LC2 on both machines):
encrypt(encrp, mask)
char encrp[], mask[];
{
int i;
for (i=0; i<6; i++)
encrp[i] ^= mask[i];
}
Just for yuks, I coded the same thing by hand in assembler and it requied
12 bytes.
The best strategy for programming the Amiga might be to make libraries and
write small front end programs. This will share code and will reduce
memory requirements.
Not only is ALINK a memory hog, but it is slow. It is not smart enough
to read in it's libraries all at once, or it might be faster. Too bad
Amiga.lib is 74K, or it might be faster, too. I have watched ALink run
whle the workbench showed dynamically how it used the ram. Alink actually
used more ram after it started writing out the executable file (?!?).
Before putting any blame on the folks at Amiga for the woes of AmigaDos,
it might be better to keep in mind that AmigaDos was written by MetaComco
NOT AMIGA. Amiga is responsible for everything from Trackdisk.device
down, and everything I see there is super! Intuition, on the highest level,
also seems to be pretty darn good.
What Amiga can do to make AmigaDos better might be limited by the software
that requires the standard AmigaDos startup stuff.
I am no Unix expert, but aren't ports and pipes (between processes) the
same (sorry, but I am ignorant if they aren't). If you refer to pipes on
the command line, I am glad tht Amiga left them out rather than tying up
RAM or using floppies for the piped data. I have these pipes available to
me under MS DOS all day, but I rarely use them and see no absolute need for
them.
Someone posted a source to unix-style ls for the Amiga, including wildcards,
etc. So who cares if the Amiga doesn't do wildcards nice, it does now!!
This ls also sorts the directories by date and time and alphabetically too!
This ought to make the disk directory format less of an issue (although it
does take a while to enumerate (expand) wildcards).
Consider this - the Amiga is making a new standard that in most ways is
better than the old ones (unix and MS Dos included here). To me it is
no worse than Unix to program for, and light years better than MS DOS.
Given time, the Amiga will mature into something that might make us all
(except for the religious) forget unix. The only problems seem to be
software, and software is real cheap and can be easily replaced. Compared
to the 8 bit machines, the Amiga is a godsend. Compared to the IBM PC and
the Atari ST (I have not heard about any standard programatic interfaces
or a standard language or anything for it) and the Mac, the Amiga is a
DREAM to program on.
Put that in your pipe and smoke it!acs@amdahl.UUCP (Tony Sumrall) (01/24/86)
In article <373@3comvax.UUCP>, mykes@3comvax.UUCP (Mike Schwartz) writes: > Someone posted a source to unix-style ls for the Amiga, including wildcards, > etc. So who cares if the Amiga doesn't do wildcards nice, it does now!! Given my primary background (IBM mainframe-land), I'm quite pleased with the wildcarding scheme provided. The only thing I'd ask is for MORE wildcarding along the lines (but not necessarily the semantics) of UNIX shells and regular expressions. -- Tony Sumrall ...!{ihnp4,hplabs,amd,sun}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. or its employees. ]
ins_ampm@jhunix.UUCP (Michael P McKenna) (01/29/86)
In article <373@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: > > >I am no Unix expert, but aren't ports and pipes (between processes) the >same (sorry, but I am ignorant if they aren't). If you refer to pipes on >the command line, I am glad tht Amiga left them out rather than tying up >RAM or using floppies for the piped data. I have these pipes available to >me under MS DOS all day, but I rarely use them and see no absolute need for >them. > Most of the following is an explanation of pipes. If you are experienced with Unix you will probably want to skip it. Ports and pipes are quite definitely NOT the same. Message ports on the Amiga provide for interprocess communication, i.e. for two (or more) processes to 'talk' to each other. Pipes take the output of one command and use it as the input of the next command, IN A WAY THAT IS TRANSPARENT TO THE COMMANDS THEMSELVES. It's that last bit that is important. Pipes provide a way of tying simple programs together to do more complex operations. This is a key part of the Unix philosophy. Ideally each command does one task and does it well. For example consider the Unix commands 'pr' and 'lp'. The command 'pr -k foofile' produces the contents of foofile on standard output in k columns. The command 'lp foofile' sends foofile to a line printer, if no file is given then standard input is used. Now if we type 'pr -3 foofile | lp' then the pr command produces foofile in 3 columns, this output is sent to the lp command which prints it. One could argue that a column option could be added to lp rather than using a pipe but there are good reasons for not doing this. 1. It makes the lp program larger, and therefore harder to maintain. 2. lp has options for controlling destination printer, number of copies, etc. Providing many options to a command makes it harder for the user to remember what they do. 3. The user might want multi-column output for other commands. Which is simpler, adding a multi-column output to every command where it might be wanted or allowing the user to pipeline commands? As a another short example, should every command that produces output have a sort option? Isn't it easier to pipe the output to a sort routine? Each command is then smaller and the user has less to remember. A more experienced user might notice that we can pipeline operations by using I/O redirection, i.e. instead of 'pr -k foofile | lp' we could type 'pr -k foofile >temp' 'lp <temp' (or in this case 'lp temp') This is not quite the same thing though. In a pipeline all commands run simultaneously (when their respective input is available). Also with a pipe you type the command in and forget about it. Using I/O redirection, you have to type a new command for each step (more than just two commands can be included in a pipeline). So why aren't pipes in AmigaDOS? I suspect it is because of memory limitations. I don't know how much memory a pipe uses but consider that there is overhead in setting it up, plus the actual buffer area, plus the added size of the operating system. >Someone posted a source to unix-style ls for the Amiga, including wildcards, >etc. So who cares if the Amiga doesn't do wildcards nice, it does now!! >This ls also sorts the directories by date and time and alphabetically too! >This ought to make the disk directory format less of an issue (although it >does take a while to enumerate (expand) wildcards). > NOT THE SAME THING! In Unix the shell expands wildcards, NOT the individual command. In fact there is no way for the command to know that a wildcard was used in invoking it! This means that: 1. A consistent wildcard system is used for all commands. Since the shell, not the commands expand the wildcards the same wildcards apply to every command. 2. When you write a program you don't have to do any wildcard expansion, the system handles it for you. >Consider this - the Amiga is making a new standard that in most ways is >better than the old ones (unix and MS Dos included here). To me it is >no worse than Unix to program for, and light years better than MS DOS. >Given time, the Amiga will mature into something that might make us all >(except for the religious) forget unix. Agreed, but only if users point out the shortcomings of the current system and offer constructive criticism. I consider the lack of pipes and wildcards a deficiency in an otherwise nice operating system, and hope that they will be added in the future. Dwight S. Wilson
peter@baylor.UUCP (02/13/86)
Regarding the memory overhead of pipes:
There is no reason you couldn't fake pipes in AMIGADOS by creating a dummy
device called "PIPE:<command>", not so?
The overhead for a pipe on UNIX is one file descriptor plus 4K (the size of a
pipe in the implementations I'm familiar with), assuming you don't buffer the
pipe on disk (in which case it's 1 fd plus 4K, since it usually spends its
whole life in the disk cache).
The reason the AMIGA doesn't have such things is obvious: the authors weren't
UNIX people and didn't know about them.
--
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076mykes@3comvax.UUCP (Mike Schwartz) (02/24/86)
If you want "pipes" (like those in Unix or MS DOS), AmigaDos provides a real simple way to implement them - without designing custom devices, etc. The statement: CAT file | MORE can be done on the Amiga using two commands: CAT >PIPE-TEMPORARY-FILE file MORE <PIPE-TEMPORARY-FILE This is not as friendly as the original way, but there is an easy solution. Write a small wedge between the CLI and the user. This wedge can use gets() to input strings (therefore it will look transparent to the user), then can use the Exec() function of AmigaDos to turn the first type of command into the second. When command lines without pipes are entered, the "wedge" program simply uses Exec() to execute the command line as typed. My understanding is that TRIPOS supports more than one CLI and that at Amiga, they chose to use the one that required the least amount of memory (a real good choice in my opinion). With a little bit of programming, a custom CLI can also be done.