paulsc@orca.UUCP (01/27/87)
In article <1565@cit-vax.Caltech.Edu> jon@oddhack.UUCP (Jon Leech) writes: > It's not clear to me from what I've read so far if minix supports >a long-model compiler. I guess this is really a question about ACK, but in >any case, I'd appreciate hearing from someone in the know. I went to the MINIX BOF at USENIX last week. Andy T. said the compiler supports only the small model, but MINIX supports 64K text (code segment), 64K data (data segment) and 64K stack (stack segment) (like "split I and D" on some PDP-11s). If you have a cross compiler, you can generate programs that use 192 Kbytes (3 * 64K) of memory. If the native compiler generates something like the ".text" and ".data" pseudo-ops, it might not be too difficult to hack the native assembler and native linker to generate the "split I and D" object files. Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA tektronix!orca!paulsc
m5d@bobkat.UUCP (01/30/87)
In article <2289@orca.TEK.COM> paulsc@orca.UUCP (Paul Scherf) writes: >In article <1565@cit-vax.Caltech.Edu> jon@oddhack.UUCP (Jon Leech) writes: >> It's not clear to me from what I've read so far if minix supports >>a long-model compiler. I guess this is really a question about ACK, but in >>any case, I'd appreciate hearing from someone in the know. > >I went to the MINIX BOF at USENIX last week. Andy T. said the >compiler supports only the small model, but MINIX supports 64K >text (code segment), 64K data (data segment) and 64K stack >(stack segment) (like "split I and D" on some PDP-11s). > ... >Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA >tektronix!orca!paulsc I have BIG BIG problems believing that Minix allows separate code, data, and stack segments. This is NOT small model, at least not as defined by Intel. In fact, it's no model at all: Small: one code seg, one data seg (incl. data, stack, and constants) Compact: code, data, stack, and "memory" Medium: one code seg. per module, only one each data, stack, "memory" Large: one code seg & one data seg per module, one stack and one "memory" The "memory" segment is available from some Intel languages. I think there's another model in which everything is in one segment; this is usually used for 8085 compatibility. It could be that PC-DOS calls this 8085 model "small". There are also clever ways of having "compact" sub-sections in a "large" system; see relevant Intel literature (the PLM-86 guide is the most informative. In all the models except "small" (or 8085 model, which is almost the same for the purposes of this discussion), pointers MUST be 32 bits. Why? Because otherwise the location referenced by the pointer cannot be determined. Consider the C statemnt x = *p; where "p" is a 16 bit pointer. Which segment register should be used to form the address? Well, in "small" model we only have two choices, so this MUST be a reference within the data segment, either to static dtata, something on the stack, or a constant. Note that if "p" actually was initialized to the address of a function, the statement above WOULD NOT retrieve the first word of the function. On the other hand, in this statement (*p)(x); it is clear to the compiler that "p" is being used to point to code, and so it will generate an indirect CALL. In fact, because of the way the iAPX-86 uses the segment registers, the data-manipulation references will use DS (or SS) without the compiler having to do a thing; likewise, the indirect CALL will fetch the value of the pointer, then form the code address with CS. Why do I think it's important that Minix use 16 bit pointers? Because it seems to me that having hard (i.e. 32 bit non-relocatable pointers) pointers makes a correct implementation of fork() impossible. Consider this: ... char *p; p = func_which_returns_a_pointer(...); if (fork()) *p = 'a'; else *p = 'b'; During the call to fork(), the operating system must copy the data of the parent process for the child (the code need not be copied). If pointers are 16 bits long, this works fine; the child process refers to its own private copy of the space pointed to by "p". The code works porperly because when "p" is referenced the current value of DS is consulted when the ultimate 20 bit address is formed. Both processes have different values in DS. BUT, if pointers are 32 bits, then a segment base address exists in the value of "p". There is no possible way that the operating system can find this absolute address and change it during the fork(). The new process will have a different DS, but the reference through "p" will in both processes refer to the exact same memory location. The problem of absolute pointers also arises if process swapping is to be considered. There is a possible solution to this. If the compiler generates pseudo code which is interpreted, then all problems dissappear. The interpreter can provide any view of memory it wants. Alternatively, the compiler could generate calls to library functions, or blocks of code in-line, for each pointer reference. Of course, there is cost in the form of lower performance. In the case of Minix on a 680?0 without memory management hardware, I see a similar problem. If anyone has some ideas on another way this could be solved, I'd be interested. -- |The first 15 minutes takes a long time;| +---the next 15 minutes takes forever---+ [[Mike McNally, a computer guy at Dallas's own Digital Lynx Inc.]] [[uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474]]
ddl@husc6.UUCP (02/02/87)
In article <500@bobkat.UUCP>, m5d@bobkat.UUCP (Mike McNally ) writes: > I have BIG BIG problems believing that Minix allows separate code, > data, and stack segments. This is NOT small model, at least not as > defined by Intel. In fact, it's no model at all: MINIX may well support code, data, stack, and even more. Just because C can't hack it... There are also ways to use more memory while still preserving fork() semantics and swapability. In OS I implememted two "extended" memory schemes: A process usually starts out life with es=ds=ss. There are system calls to allocate additional segments which are assigned descriptors (you know, small non-negative integers...) and a call to set your segment registers to use this memory. This all works without giving up fork() and swapping because processes know only about these descriptors. For processes that insist on knowing absolute segment locations there is a call to set "NONSEG" mode and a call to find out a segment's address. A non-segmented process will never be moved in memory and is not allowed to fork(). It is allowed to vfork(). Dan Lanciani ddl@harvard.*
m5d@bobkat.UUCP (02/03/87)
In article <1151@husc6.UUCP> ddl@husc6.UUCP (Dan Lanciani) writes: >MINIX may well support code, data, stack, and even more. Just because C can't >hack it... There are also ways to use more memory while still preserving >fork() semantics and swapability. In OS I implememted two "extended" >memory schemes: A process usually starts out life with es=ds=ss. There >are system calls to allocate additional segments which are assigned >descriptors (you know, small non-negative integers...) and a call to >set your segment registers to use this memory. This all works without >giving up fork() and swapping because processes know only about these >descriptors. ... > > Dan Lanciani > ddl@harvard.* OK, OK, let me re-state my position. I agree that given enough run-time code, either called explicitly by the programmer (gag me, gag me) or generated by the compiler, anything can happen. The compiler could even generate code to check pointer values every time a pointer is dereferenced. This begins to sound like a pseudo-code interpreter approach. Think of the overhead! It makes my knees itch. However, if you're willing to live with it (which no doubt many people are to get a cheap secure system on their machines), GREAT! I don't mean to condemn. I was just trying to point out that with straight code it's bad to pin memory locations. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
thomps@gitpyr.UUCP (02/03/87)
There has been some discussion about compiler models. According to doctor
Tannebaum's book, MINIX supports only :
(1) All code and data (including stack) in one 64 K segment
(2) All code in one 64K segment and data and stack in another 64K segment
with data starting at the bottom and growing up and the stack at the top
and growing down (I think. I don't have the book handy as I write this)
The C compiler distributed with MINIX supports only (1). A tool is
provided to help with cross-compiling from MS-DOS to get too.
--
Ken Thompson Phone : (404) 894-7089
Georgia Tech Research Institute
Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thompsjoe@dayton.UUCP (Joseph P. Larson) (02/04/87)
In article <3021@gitpyr.gatech.EDU> thomps@gitpyr.gatech.EDU (Ken Thompson) writes: >with data starting at the bottom and growing up and the stack at the top >and growing down (I think. I don't have the book handy as I write this) I always thought stacks grew up. I think (and hope!) that you've got the two reversed! ("Where, or where have the standards gone? Where, oh where may they be?") -- UUCP: ihnp4!rosevax!dayton!joe Joe Larson ATT : (612) 375-3537 Dayton Hudson Department Store Company (standard disclaimer...) 700 on the Mall Mpls, Mn. 55408
thomps@gitpyr.UUCP (02/05/87)
In article <383@dayton.UUCP>, joe@dayton.UUCP (Joseph P. Larson) writes: > In article <3021@gitpyr.gatech.EDU> thomps@gitpyr.gatech.EDU (Ken Thompson) writes: > >with data starting at the bottom and growing up and the stack at the top > >and growing down (I think. I don't have the book handy as I write this) > > I always thought stacks grew up. I think (and hope!) that you've got the > two reversed! ("Where, or where have the standards gone? Where, oh where > may they be?") While it may seem counter intuitive, the computer world is full of stacks which grow down. This is the case with the 8086/8088 so that my above statement turns out to be correct. My experience has been that stacks grow in whichever direction happens to be convenient to the designer and implementer of the stack. The fact that the stacjk is inverted does not affect the paradigm at all. It is still a LIFO structure. The stack also grows downward on an Intel 8080 and Motorolla 6800, two early microcomputers so I hardly think that the direction stacks grow in memory is standardized. -- Ken Thompson Phone : (404) 894-7089 Georgia Tech Research Institute Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!thomps
herman@ti-csl.UUCP (02/05/87)
in article <383@dayton.UUCP>, joe@dayton.UUCP (Joseph P. Larson) says: > I always thought stacks grew up. I think (and hope!) that you've got the > two reversed! ("Where, or where have the standards gone? Where, oh where > may they be?") > -- > UUCP: ihnp4!rosevax!dayton!joe Joe Larson > ATT : (612) 375-3537 Dayton Hudson Department Store Company > (standard disclaimer...) 700 on the Mall > Mpls, Mn. 55408 Sorry, but stacks in general grow downwards in memory. Just look at the description of the PUSH and POP instructions on various processors. They usually pre-decrement the stack pointer on PUSH, and post-increment on POP. Memory management units, or processors with memory management facilities on board, usually provide a special segment type for segments that grow downwards in memory, just for stack applications (see Expand Down or ED bit on the 80286, or the Expansion Direction bit on the PDP11/45). -- Herman Schuurman ARPA: herman%TI-CSL@CSNET-RELAY.ARPA Texas Instruments Inc. CSNET: herman@TI-CSL PO Box 226015 M/S 238 USENET: {ut-sally,convex!smu,texsun,rice}!ti-csl!herman Dallas, Texas 75266 VOICE: (214) 995-0845
merlin@hqda-ai.UUCP (David S. Hayes) (02/06/87)
In article <500@bobkat.UUCP>, m5d@bobkat.UUCP (Mike McNally ) writes:
-> I have BIG BIG problems believing that Minix allows separate code,
-> data, and stack segments. This is NOT small model, at least not as
-> defined by Intel. In fact, it's no model at all:
->
-> Small:
-> one code seg, one data seg (incl. data, stack, and constants)
-> Compact:
-> code, data, stack, and "memory"
-> Medium:
-> one code seg. per module, only one each data, stack, "memory"
-> Large:
-> one code seg & one data seg per module, one stack and
-> one "memory"
MINIX normally uses CS == SS == DS, putting code, data, and
stack in the same 64K chunk. Obviously not very suitable. In the
"separate I and D space" model, CS is reassigned, but SS == DS.
-> In all the models except "small" (or 8085 model, which is almost the
-> same for the purposes of this discussion), pointers MUST be 32 bits.
-> Why? Because otherwise the location referenced by the pointer cannot
-> be determined. Consider the C statemnt
->
-> x = *p;
->
-> where "p" is a 16 bit pointer. Which segment register should be used
-> to form the address? Well, in "small" model we only have two choices,
-> so this MUST be a reference within the data segment, either to static
-> dtata, something on the stack, or a constant.
[ deleted ]
-> Why do I think it's important that Minix use 16 bit pointers? Because
-> it seems to me that having hard (i.e. 32 bit non-relocatable pointers)
-> pointers makes a correct implementation of fork() impossible.
[example deleted]
-> If pointers are 16 bits long, this works fine; the child process
-> refers to its own private copy of the [data] space.
-> BUT, if pointers are 32 bits, then a segment base address exists
-> in the value of "p". There is no possible way that the
-> operating system can find this absolute address and change it
-> during the fork(). The new process will have a different DS,
-> but the reference through *p will in both processes refer to
-> the exact same memory location.
->
-> The problem of absolute pointers also arises if process swapping is to
-> be considered.
A very fine analysis, pointing out a problem I had not
worried about previously. Of course, I'm running on a 286-based
PC/AT.
Within the 286 protected mode, each process may have its own
set of segments. The operating system may map each any process
segment number into any physical location it wants. References to
unmapped segments elicit a trap to the OS.
A swapping, shared-text-space memory allocation scheme is
only practical on machines that support some form of memory
protection. While we may be able to put this capability into
MINIX for the AT, the PC/XT and its look-alikes will be left
behind. This is vaguely distrubing to me... Will we end up
giving away the standardization that Andy Tanenbaum has given us?
How much compatibility should we be willing to trade for the sake
of increased capability?
--
David S. Hayes, The Merlin of Avalon
PhoneNet: (202) 694-6900
ARPA: merlin%hqda-ai.uucp@smoke.brl.mil
UUCP: ...!seismo!sundc!hqda-ai!merlinjoe@dayton.UUCP (02/06/87)
In article <13647@ti-csl.CSNET> herman@ti-csl.CSNET (Herman Schuurman) writes: >in article <383@dayton.UUCP>, joe@dayton.UUCP (Joseph P. Larson) says: >> I always thought stacks grew up. I think (and hope!) that you've got the >> two reversed! ("Where, or where have the standards gone? Where, oh where >> may they be?") > >Sorry, but stacks in general grow downwards in memory. Just look at the >description of the PUSH and POP instructions on various processors. They >usually pre-decrement the stack pointer on PUSH, and post-increment on POP. Giggle. *THINK* about it. If you are PUSHing something and you pre-decrement the stack pointer, it is going to point UPWARDS in memory. Using Macro-11: movl arg, -(SP) ; push movl (SP)+, arg ; pop Pre-decrement of SP for a push makes the stack grow up... -- UUCP: rutgers!dayton!joe Dayton Hudson Department Store Company ATT : (612) 375-3537 Joe Larson/MIS 1060 (standard disclaimer...) 700 on the Mall Mpls, Mn. 55408
joe@dayton.UUCP (02/06/87)
In article <383@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: >In article <3021@gitpyr.gatech.EDU> thomps@gitpyr.gatech.EDU (Ken Thompson) writes: >>with data starting at the bottom and growing up and the stack at the top >>and growing down (I think. I don't have the book handy as I write this) > >I always thought stacks grew up. I think (and hope!) that you've got the >two reversed! ("Where, or where have the standards gone? Where, oh where >may they be?") Okay! I have gotten a fair amount of mail about this. And so far, *everyone* has agreed with me but didn't know it. So I guess it's time to discuss terminology... Per my old instructors and several co-workers, stacks grew up. That is, they start in high memory and grow towards zero. Why is this growing up? Because when you picture a stack, you but the low-order addresses near the top of the page. You highest address is at the bottom of the page of paper. Thus, although you are moving towards the low-order addresses, it was discussed as moving up. Okay. So it sounds backwards. But this is the terminology we all used. If this is different from what y'all used, that's fine. I intend to see what my textbooks used when I get home tonight and will post a note telling people how I got the egg off if it doesn't correspond to this set of terminology. But don't everyone send me mail telling me they think it's backwards. (If you want to tell me that it's NOT backwards, I won't mind, of course). -Joe -- UUCP: rutgers!dayton!joe Dayton Hudson Department Store Company ATT : (612) 375-3537 Joe Larson/MIS 1060 (standard disclaimer...) 700 on the Mall Mpls, Mn. 55408
nerd@percival.UUCP (02/06/87)
>>with data starting at the bottom and growing up and the stack at the top >>and growing down (I think. I don't have the book handy as I write this) >I always thought stacks grew up. I think (and hope!) that you've got the >two reversed! I don't recal what the stack does on the 80?86 but on the 8080, z80, and on the 680?0 parts it starts at high memory addresses and grows downwards. This means that when you 'push' or move xx,-(a7) the stack pointer will be decremented by the size of the object you are 'pushing' and the object will then be copied to the location now being pointed to by the stack pointer. I don't know if I just mis-interpreted 'growing up' or if it is a genuine error. The first included peice looks right to me, the heap being dinamicaly alocated starting low in the segment and growing to higher addresses as the need arises and the stack doing the oposite 'till they meet and everything blows up. -- If my employer knew my opinions he would probably look for another engineer. Michael Galassi, Frye Electronics, Tigard, OR ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd
mcvoy@uwvax.UUCP (02/06/87)
In article <383@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: >I always thought stacks grew up. I think (and hope!) that you've got the As someone here pointed out, "You must have spent your life standing on your head" :-) Stacks almost always (always?) grow down. You put the text (executable) at the bottom, data after that, and the stack starts at the top and grows down. This becomes more obvious when you consider sharing memory and growing stack & data segments. See Knuth, Chapter 2. -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
rmtodd@uokmax.UUCP (02/08/87)
In article <264@hqda-ai.UUCP>, merlin@hqda-ai.UUCP (David S. Hayes) writes: > Within the 286 protected mode, each process may have its own > set of segments. The operating system may map each any process > segment number into any physical location it wants. References to > unmapped segments elicit a trap to the OS. > > A swapping, shared-text-space memory allocation scheme is > only practical on machines that support some form of memory > protection. While we may be able to put this capability into > MINIX for the AT, the PC/XT and its look-alikes will be left > behind. This is vaguely distrubing to me... Will we end up > giving away the standardization that Andy Tanenbaum has given us? > How much compatibility should we be willing to trade for the sake > of increased capability? The problems with relocating data segments about only arise if your data+stack space is greater than 64K. If your program is in one of the two standard models MINIX apparently supports (code+data+stack in 64K, or "split I and D" 64Kcode, 64K data+stack), then all you need to shift about the data section is to change DS and SS to point to the segment's new location. Assuming the program isn't doing any clever assembly-language tricks in directly referencing the DS and SS registers, the program should still work. In effect, the DS and SS registers are acting as the segment-mapping registers of 286 protected mode and giving us (for these size programs) much the same capability. What all this really means is that on the XT you can't extend MINIX to do both swapping/process moving/etc. AND large data or code segments. On the AT you could do both, but on the XT you'll have to choose which one you want. Frankly, with only 640K in an XT I don't think large code/data programs are too feasible in a multitasking environment anyway, especially if you won't be able to swap. As for trading compatibility off for capability, well, if you want to use large code or data on your AT, you'll have to trade away compatibility to some extent. But if care is taken to write the new software (e.g the swapper) with appropriate #ifdefs, it should be possible to have the same source code on both XT and AT (just stick in, say, #define AT_LARGE_MODEL if you want it). Programs written under the new "large" AT system may end up too big to port to the XT, but then the same may be true of programs written on Amiga/ST/etc. (if and when MINIX is available for those machines). ___________________________________________________________________________ "You should be very careful when getting a second-hand space-ship. They can be very unreliable." -- Vila Restal ___________________________________________________________________________ Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd
rpw3@amdcad.UUCP (02/08/87)
Well, there have been machines in which the stack grew upwards (and to
avoid any more of this silly re-interpretation, by "up" I mean in the
direction of higher addresses in memory, not up, down, or sideways on
a piece of paper).
On the PDP-8, the PDP-10, and the IBM-360 (before C came around),
stacks grew up (the PDP-10 had hardware push and pop, the other didn't).
To my knowledge, the PDP-11 was the first machine in which stacks went
the "wrong" way (from the "traditional" point of view). Later, people
figured out that it made more sense on a 360 for the stacks to go the
other way.
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun}!redwood!rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403grr@cbmvax.UUCP (02/09/87)
In article <14659@amdcad.UUCP> rpw3@amdcad.UUCP (Rob Warnock) writes: > >To my knowledge, the PDP-11 was the first machine in which stacks went >the "wrong" way (from the "traditional" point of view). Later, people >figured out that it made more sense on a 360 for the stacks to go the >other way. >Rob Warnock Systems Architecture Consultant To save beating around the bush, one good reason for having stacks grow down is that many architectures do not support signed indexing off registers. This makes it difficult to access things pushed up on the stack by using stack pointer relative addressing. Of course you can always add a frame pointer, but that's another register down the tubes and you usually don't have that many to start with... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
russ@crlt.UUCP (02/11/87)
In article <500@bobkat.UUCP>, m5d@bobkat.UUCP writes: >I have BIG BIG problems believing that Minix allows separate code, >data, and stack segments. This is NOT small model, at least not as >defined by Intel. In fact, it's no model at all: > > Small: one code seg, one data seg (incl. data, stack, and constants) > Compact: code, data, stack, and "memory" > Medium: one code seg. per module, only one each data, stack, "memory" > Large: one code seg & one data seg per module, one stack and > one "memory" Memory models supported by Lattice C: S (small): 64K code, 64K data/stack. 16 bit pointers. P (Prog): To 1 MB code, 64K data/stack. 16 bit data pointers. Function pointers by lookup table. D (data): 64K code, to 1 MB data, 64K stack. 32 bit pointers. L (large): To 1 MB code, 1 MB data, 64K stack. 32 bit pointers. >[...] It could be that PC-DOS calls >this 8085 model "small". Nope, the combined I&D (64K total) model is called the 8080 model. >In all the models except "small" (or 8085 model, which is almost the >same for the purposes of this discussion), pointers MUST be 32 bits. >Why? Because otherwise the location referenced by the pointer cannot >be determined. The 8080, small and P models can use 16-bit pointers, because they have only 64K of data/stack space. Separate I & D segments do not affect the required pointer size unless you want to do something silly like write over your code. The P model (with more than 64K of code) can still use 16 bit pointers to data; its pointers to functions are indirect through a table of function addresses (32 bits/entry, of course). So far as relocatability is concerned, any 8080 or S model program can be shoved to an arbitrary segment address dynamically and all pointers will still be valid. A P model program could survive relocation of its data segment; if the code was re-entrant and re-used, then a P model program could also be fork()ed without difficulty. D and L model programs, forget it. It looks like Minix supports the 8080 and S models only, which is not suprising. -- The above opinions and figures are mine; my employer endorses them implicitly. "They that can give up essential liberty to Russ Cage, Robust Software Inc. gain a little temporary safety, deserve neither ihnp4!itivax!m-net!russ liberty nor safety." -- Ben Franklin (Do not reply to me at CRLT, it loses news and mail regularly. Use path above.) NSA food>terrorist DES RSA KGB cocaine cryptography RSA TEMPEST fnord Hail Eris!
steve@warwick.UUCP (02/15/87)
In article <385@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: > >Per my old instructors and several co-workers, stacks grew up. That is, >they start in high memory and grow towards zero. > >Why is this growing up? Because when you picture a stack, you but the >low-order addresses near the top of the page. You highest address is >at the bottom of the page of paper. Thus, although you are moving towards >the low-order addresses, it was discussed as moving up. > But I've always writtem my addresses left to right on the paper - my stacks grow left not up or down!! Steve. -- _______________________________________________________________________________ |UUCP: ...!ukc!warwick!steve | Steve Rumsby | |JANET: steve@uk.ac.warwick.uu | Maths Institute | |ARPA: steve%warwick.uucp@ucl-cs.ARPA | University of Warwick | |BITNET: steve%uk.ac.warwick.uu@UK.AC | Coventry | | | CV4 7AL | |PHONE: +44 203 523523 x2657 | ENGLAND | ------------------------------------------------------------------------------- "For every problem there is one solution which is simple, neat, and wrong." -- H. L. Menken