Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-k.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!rochester!cmu-cs-pt!cmu-cs-k!agn
From: agn@cmu-cs-k.ARPA (Andreas Nowatzyk)
Newsgroups: net.micro,net.micro.pc
Subject: Re: Standard, What standard???
Message-ID: <287@cmu-cs-k.ARPA>
Date: Mon, 25-Feb-85 18:45:13 EST
Article-I.D.: cmu-cs-k.287
Posted: Mon Feb 25 18:45:13 1985
Date-Received: Fri, 1-Mar-85 07:38:20 EST
References: <143@idmi-cc.UUCP> <810@sjuvax.UUCP>, <56@daisy.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 21
Xref: watmath net.micro:9532 net.micro.pc:3414


Defending the 80x86's segmented architecture, Mr. Schachter writes:

> Finally, although I am not a fan of segmentation a la Intel, I am compelled
> to point out that my company has done quite a lot within the Intel archi-
> tecture.  Our experience in writing complex Computer-Aided-Engineering
> programs is that if you need segments >  64kB, you probably don't know
> what you are doing: there exists a better algorithm to do what you want to
> do.  This is not always true but it is true often enough that the Intel
> architecture doesn't cause us much pain.  In summary, while segmentation
> looks bad, it really doesn't hurt too much.

Using said software (on Daisy's 80286-based CAD workstations), I find
the opposite to be true: Segmented addressing with a 16bit limit
is a royal pain in the neck! I ran into quite a few problems that were
directly related to the fact that some table in some data structure had
to fit into 64K byte. While the CAD software itself is reasonable, I
wished more than once that they had used a 68K or 16/32K processor.

  Andreas.Nowatzyk              ARPA:   agn@cmu-cs-k.ARPA
                              USENET:   ...!seismo!cmu-cs-k!agn