Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!uceng!minerva!dmocsny
From: dmocsny@minerva.che.uc.edu (Daniel Mocsny)
Newsgroups: comp.arch
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <7920@uceng.UC.EDU>
Date: 31 Mar 91 13:18:13 GMT
References: <1991Mar27.172325.10800@sj.nec.com>
Sender: news@uceng.UC.EDU
Organization: University of Cincinnati, Cin'ti., OH
Lines: 35

In article <1991Mar27.172325.10800@sj.nec.com> koll@NECAM.tdd.sj.nec.com (Michael Goldman) writes:
>Instead, I will simply point out that segments add
>complexity to programming, which results in bugs, which take time to find
>and to fix, which delays time-to-market, which costs money.

Incidentally, so does having more than one architecture to support.
If the solution to a segmented architecture is a segmented market,
one has to wonder whether that is a step forward or backward.

Almost everybody probably can agree that segments do lousy
things to the programmer. (Even though I do my best to hide behind
compilers, I've done brilliant things like linking in the wrong
memory model of a function library, which generated an incomprehensible
linker error, for which the reference manual explanation was 
completely misleading, and cost me about a day to figure out where 
I screwed up).

However, what is the best way to fix the segment problem? By having
50 dozen superior new architectures to grapple with?

So here is a question. Which would you rather program, 1 lousy
architecture, or N nice but mutually incompatible architectures?
For what minimum value of N does the 80x86 turn out to be simpler?

My guess is that today the 80x86 is by far the simplest architecture 
to program *per customer*. All the more reason to develop completely
portable language and user-interface standards, and then let the
hardware vendors compete to see how well they can run generic
programs. Instead of having hardware vendors compete to see how
many programmers they can capture.


--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu