Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!romkey@mit-borax
From: romkey@mit-borax@sri-unix.UUCP
Newsgroups: net.micro
Subject: Re: why buy an apple
Message-ID: <12055@sri-arpa.UUCP>
Date: Tue, 27-Sep-83 03:14:25 EDT
Article-I.D.: sri-arpa.12055
Posted: Tue Sep 27 03:14:25 1983
Date-Received: Fri, 30-Sep-83 00:22:13 EDT
Lines: 73

From:  John L. Romkey <romkey@mit-borax>

Hi, since I've already flamed about it, I thought maybe I should try to
answer your questions in a level-headed manner.

1) The 8088 addressing 1Mb of RAM.

The 8088 is a 16 bit processor which doesn't have pretenses to being a 32
bit processor, unlike the 68000 and 16032. A problem is that it's really
nice if your processor registers are wide enough to hold memory pointers. In
the 8088, this is a problem because people really do like to use more than
64K of memory, but that's all that 16 bits can address. So Intel made the
memory segmented. The idea is that there are also 16 bit segment addresses,
one for code, one for data, one for stack, and one extra one (which really
is called the "extra segment"). What you do to make a 20 bit address out of
a 16 bit data address is to take the 16 bit data segment address, shift it
left by 4 (multiplying it by 16), and add it to the data address. This
produces a new 20 bit address. Thus if you're looking at address 234B (hex)
and your data segment is 0800 (hex), then the physical address will be
0A34B, a 20 bit number.

There are some advantages and disadvantages to this scheme. Although you can
access more than 64K of address space (total), it's often inconvenient and
rather clumsy. The 8088 isn't a 32 bit processor, and you really feel it
when you're doing extensive work with pointers. Also, taking two random
pairs of segments and offsets and comparing them is a bit more work than
you'd really hope for.

2) I/O redirection, path searches, and the single user machine.

I/O redirection is sort of based on the idea that a program has a "standard
input" and a "standard output". These are usually associated with your
terminal, but it's sometimes useful to associate them with other things,
like files. Then you can do something like
                    dir > files
which will run the directory command and put everything it sends to standard
output into the file "files" instead. Then you can edit it, or print it, or
mail it to your best friend if you want. Or, you can do something called
piping. The unix way of writing it is with a |. You can say
                    dir | sort
and what this does is to take the standard output of dir and use it as the
standard input of sort. The above command line would give you a sorted
directory listing. If a system is multitasking, piping can be done by
buffering data in the operating system and awakening or putting to sleep
processes when necessary. If it's not, then you have to put all the output
of one program in a file and then have the other program read from that file
when it reads from standard input.

You might notice that this scheme forces terminal I/O to look a lot like
file I/O. In fact, it forces a move towards the position where you just
basically have streams which you read characters from and write characters
too.

Search paths are (I think) really only useful when you have a file system
which can have multiple directories (or perhaps when you have a whole lot of
disk drives on your machine). If you can have multiple directories, a search
path tells the command interpreter where to look for programs when you type
a command. Suppose your search path is /bin;/local;/etc. Then, when you type
the command "foo", the command processor will probably see if it has a built
in command of that name (thought it would be nicer if it waited till it had
checked elsewhere) and if it doesn't, it will look for a program named
"/bin/foo" or "/local/foo" or "/etc/foo" and try to execute it if it finds
it.

I think that I/O redirection and search pathes can be really useful, even in
a single user system. Just because a system can't have multiple processes
doesn't mean that you shouldn't have a decent working environment. Of
course, I worked for years without knowing about these things and would have
thought them useless if anybody had told me about them.

This message becomes to long. To be continued.
                                                            - John Romkey
                                                              romkey@mit-borax