Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!excelan!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Xerox sues Apple!!!
Message-ID: <343@sixhub.UUCP>
Date: 28 Dec 89 21:14:38 GMT
References: <6767@tank.uchicago.edu> <1989Dec17.112127.27333@me.toronto.edu> <332@sixhub.UUCP> <3371@rti.UUCP>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 93

I have slightly rearranged the order several quotes in order to make a
common comment on them. This was done to make the reply smaller and
easier to understand. No intent to take anything out of context.

In article <3371@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:

| It's awfully annoying that you can't, for example, use AX as an index
| register, or that you can't multiply into the DI register on most of the
| 80x86 family.  I know you can do it on the 80386 (more on this below),
| but the point is that there are so many special purpose registers on most
| of the family (like the way SI, DI, and CX cooperate to perform "string"
| operations ... with no good way to substitute any other registers for any 
| part of the operation).  This makes it difficult to perform intelligent
| register optimization, whether you are writing in assembler or writing a 
| code generator for a compiler.

He also writes:

| On the other hand, you generally have to have more instructions on an 
| Intel instruction set to accomplish anything - because things never seem 
| to be in the "right" registers.  Even on the 80386, instructions that use 
| EAX as an index register take more space than the equivalent instruction 
| to use EBX as an index register (for example).  This might be OK if the 
| Intel architecture were a RISC architecture (at least at current levels 
| of semiconductor technology, it is easier [=cheaper] to build a RISC 
| machine at a given level of performance than a CISC), but unfortunately 
| the Intel architecture (especially the 80386) is firmly on the CISC side.
| If nothing else, it would really get in the way of a RISC to have to
| decode variable-length register fields in instructions.

  I can't find any fault with any othe this. It is certainly true that
writing optimal code for the Intel processors is somewhat more difficult
than writing optimal code for the 68k, primarily because the Intel
family provides "one best way to do it" in terms of code size and speed,
and any other way is larger, slower, or both. This requires greater care
in order to insure that the right registers are free. If optimal code is
generated the Intel code is frequently smaller in terms of bytes that
the 68k code to produce the same results. This is not a claim that the
code is "faster or better than" the 68k code, just smaller.


| >   The 386 and 486 have 2 GB segments (yes GB not MB).
| 
| This is obvious even to low intelligence.

You said that, I didn't.


| >   Some applications are difficult on a linear machine without memory
| > mapping, since having separate text and data space requires some kind of
| > control, such as segments or memory management.
| 
| This is not a segmentation question - it has nothing to do with that issue.
| For example, consider the PDP-11 and VAX architectures, which have no
| segments anywhere in sight and which manage this sort of thing very well.
| What you are talking about is a memory mapping/paging/virtual memory
| function (which are more closely related to each other than any of them
| is to segmentation);  

  Sorry I didn't make that clear, that's not what I meant. I was
speaking about "separate i and d space," having the text (code) and data
addresses under separate segments. This allows (a) several processes to
share a single text segment in a multitasking o/s, and (b) allows the
write protexted text segment to be overwritten rather than swapped, if
the o/s does swapping. In point of fact some PDP-11's did have separate
i&d space, but I can't remember which. The last time I ran UNIX on an 11
was V6, if that gives you a clue.

| Look, I really can't say I "hate" the Intel architecture, it's just an 
| ugly architecture that is unnecessarily hard to write for.  I've long 
| since lost track of how much code I've written for it, but it's many tens 
| of thousands of lines of code (probably well over 100k lines) - in a 
| variety of languages and operating systems.  I'm also enough of a computer
| junkie that I'd probably get a kick out of programming ANY machine, no
| matter HOW ugly.  I just don't do a great deal with it right at the moment:
| minicomputers pay better.  If that situation changes I may very well do a
| lot more programming on them.  As computer architectures go, it's still an
| ugly architecture.

  If challenge = fun, the Intel 8085 (with 10 extra instructions aimed
at stack oriented languages), the 80186 (with builtin serial and
interrupt capability, and the GE/Honeywell 6000 36 bit machines (with 6,
9, and any multiple of 36 bit stacks) take the cake. For ease of
programming the NS32000 is the favorite I've used so far, since the
registers are about as general purpose as possible and the string
instructions allow lots of diddling. That doesn't say much about the
'goodness' of these, just the fun factor. For commercial programming
give me C anytime, and I don't CARE what the CPU might be.
-- 
	bill davidsen - sysop *IX BBS and Public Access UNIX
davidsen@sixhub.uucp		...!uunet!crdgw1!sixhub!davidsen

"Getting old is bad, but it beats the hell out of the alternative" -anon