Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!boring!jack From: jack@boring.UUCP Newsgroups: net.micro.68k,net.arch Subject: Re: FLAME!!! Re: EA orthogonality Message-ID: <6431@boring.UUCP> Date: Fri, 24-May-85 17:10:33 EDT Article-I.D.: boring.6431 Posted: Fri May 24 17:10:33 1985 Date-Received: Sat, 1-Jun-85 13:37:09 EDT References: <419@oakhill.UUCP> <6415@boring.UUCP> <557@terak.UUCP> <6417@boring.UUCP> <572@terak.UUCP> Reply-To: jack@boring.UUCP (Jack Jansen) Organization: CWI, Amsterdam Lines: 76 Xref: linus net.micro.68k:792 net.arch:1106 Apparently-To: rnews@mcvax.LOCAL I'm not sure whether Doug Pardee is serious, or just trying to keep the discussion going. I'll assume he *is* serious, and answer him anyway. Doug>The purpose of a CPU is *NOT* to be as easy to write a compiler for as Doug>possible. me> Not agreed. If a machine is simple, the compiler is simpler, and thus it me> is available sooner, doesn't have as much bugs, etc. Doug>Did I miss something here? Since when is it any concern of mine, as a Doug>user, whether the compiler is simple??? Exactly for the reasons stated above. You don't want to argue that a 4000 line compiler is easier to maintain, debug, etc. than one of 8000 lines, I hope? Doug>And I have seen no evidence that compilers for "simple" machines are Doug>available any sooner, or are any more reliable, than compilers for Doug>warpo machines. No? Get yourself a PR1ME, and try the pascal compiler :-( Now, I won't comment on the rest point-by-point, since it would be too long-winded that way. Let me just explain the following point: When you are designing a machine, you are facing two size problems: 1. How do I fit all those transistors on this little square? 2. How do I fit all those opcodes in those 16 bits? An orthogonal design is clearly good for (1), since it allows you to put use the hardware (or firmware) for calculating "x'100(a6:B)[d0]" many times. Now, to satisfy (2), you can do two things: - Make the operand fields small, so you can have many opcodes. - Make the opcode fields small, so you can have complicated operands. (I won't go into RISC here, which makes both of them small). If you take the first choice, you can have lots of nifty instructions like 'search for a one bit, and return the position in a register' or 'copy a string and translate' and those kind of things, which will *never* be used by *any* compiler (except for cobol, maybe) since most high-level language don't have a construct for that. Can you imagine a compiler that would recognize for(p=src, q=dst; *p; p++, q++) *q = table[*p]; and translate it in the above mentioned instruction? If you take the second branch, you will *not* have a string translate instruction. You will, however, have the ability to make your design orthogonal. Wirth (I think, I'm not sure) has long ago measured that the average expression had 1.5 operands. This means the half of the instructions you give will be expressible in *one* instruction, provided that the machine lets you address something on the stack as an operand. For example: a += b; orthogonal: add b(r5),a(r5) non-orthogonal: mov a(r5),r4 <-- AND MAKE SURE IT'S FREE!! add b(r5),r3 mov r3,a(r5) Now, in cycles, the first one would result in 4 memory cylces and 3 additions, and the second in 6 memory cycles and 4 additions (PLUS an additional 2 instruction decodes). Well, this has got long-winded after all, sorry for that. You may do what you want, but I'll stick to hardware that was designed by software people. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.