Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!seismo!umcp-cs!cvl!umd5!zben From: zben@umd5.UUCP Newsgroups: net.arch Subject: Re: 386 Architectural Description Message-ID: <776@umd5.UUCP> Date: Tue, 5-Nov-85 02:08:52 EST Article-I.D.: umd5.776 Posted: Tue Nov 5 02:08:52 1985 Date-Received: Fri, 8-Nov-85 05:52:40 EST References: <130@intelca.UUCP> <181@opus.UUCP> Reply-To: zben@umd5.UUCP (Ben Cranston) Distribution: net Organization: U of Md, CSC, College Park, Md Lines: 54 Summary: Sometimes compilers can ignore complexity... In article <181@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes: >> (marks quotes from the original article -CBC) >> For the convenience of compiler writers, the 80386 provides multiple >> addressing modes, a capability which ensures that high-level languages >> can be implemented in the most efficient manner possible. > ... (As a compiler writer, I know that >only a very few addressing modes are useful; beyond that they just >complicate the compiler. And as far as some of the odd ways I've seen for >encoding addressing information--if I never have to produce another segment >override byte in my life it will be a spot of joy.) ... >> The 80386 instruction set is marked by both power and flexibility. It >> offers the compiler writer and assembly language programmer a broad >> range of choices in which operations and data can be specified. >Again speaking as a compiler writer, if there's one thing that's a pain in >the... >...code generator, it's "a broad range of choices..." The fewer ways there >are to do things: > - the fewer choices the compiler has to make > - the fewer chances it gets to make the wrong choice > - the less time it has to spend making choices > - the less time the compiler-writer has to spend teaching the > compiler to make these choices >I understand the architectural attitude that has given ever-richer >instruction sets and addressing structures--but by and large these have not >only NOT been helpful to compiler writers; they've led to compilers which >are larger, slower, less reliable, and yet use an ever-decreasing subset of >the hardware's capability. Save the "broad range of choices" for assembly >language folks; give the compiler people simple, FAST machines. I think this only applies when horrid things are done to the basic machine in order to support the fancy faz-baz features. Anybody who has ever seen the Huffman-coded opcode fields for the Intel 3000 should grok this... But, the machine I mainly use has 128 registers (sort of, you can't use them all for everything) which respond to low-core addresses too. The toy (subset-of-Algol) compiler I wrote taking classes used exactly two registers. One was used for all arithmetic, the other for array subscripting. So, like, put a zero in register R0 and pretend there is a no-index mode. Write the compiler to use only simple register-to-memory operations and do its subscript calculations with ADD and MUL like G*d meant them to be, and ignore that POLY instruction... Another way of looking at it is that the basic machine will probably have been slowed down a bit to accomodate all that faz-baz, and that this is the ultimate cost. Looking at it this way just drags us back to the old "to-RISC-or-not-to-RISC" dead horse. I would be willing to bet that the complaintant here is a closet "RISC" person... :-) -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA