Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!akguc!codas!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch
Subject: Re: Addressing modes
Message-ID: <1989@peora.UUCP>
Date: Thu, 27-Feb-86 08:11:41 EST
Article-I.D.: peora.1989
Posted: Thu Feb 27 08:11:41 1986
Date-Received: Sat, 1-Mar-86 04:24:26 EST
References: <946@garfield.UUCP> <1417@sdcsvax.UUCP>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 37

> That's just the problem.  The designers of CISC machines think that they
> are making the compiler writer's job easier by supplying opcodes to
> perform high level semantics.  Unfortunately, NO ONE has yet succeeded
> in developing an instruction set which can 'directly (and optimally)'
> interpret the semantics of the source code.

Now, this is exactly the point at which the RISC/CISC debate generates into
the sort of assertions more commonly found in advertising than in research.
The fact that "NO ONE has yet succeeded" in no way demonstrates or proves
that it can't be done; this is a simple fallacy!  It involves arguing that

	(a "good" CISC machine exists) -> (one can be built)
	~(a "good" CISC machine exists)
	:. ~(one can be built)

which would be like arguing, at the time that people were trying to build
flying machines and they were all falling apart, that this meant that
it was impossible to do.

Note that in my original posting, I didn't say "interpret the semantics
of the source code," I said interpret some *representation* of the source
code.  There is a lot of work done by compilers (e.g., resolving symbolic
references, translating infix arithmetic expressions with ASCII constants
into a more manageable form, etc.) which takes a lot of time, and any
machine (such as these microcomputers they are always building projects
for in Byte that directly execute BASIC) which takes on that task will
be much slower.

The problem with the practical examples of why "it won't work" are that
invariably one group of people designed an instruction set, and put in
features that they thought, or had been told indirectly, would be "useful"
for compilers, but this group of people knew almost nothing about compiler
writing, and so they simply did it wrong.
-- 
UUCP: Ofc:  jer@peora.UUCP  Home: jer@jerpc.CCUR.UUCP  CCUR DNS: peora, pesnta
  US Mail:  MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company)
	    2486 Sand Lake Road, Orlando, FL 32809-7642