Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Computer Architecture methodology
Keywords: A Series, B6700
Message-ID: <3627@auspex.auspex.com>
Date: 8 Jul 90 17:44:38 GMT
References: <14279@burdvax.PRC.Unisys.COM> <844@tredysvr.Tredydev.Unisys.COM> <2322@l.cc.purdue.edu>
Distribution: comp.arch
Organization: Auspex Systems, Santa Clara
Lines: 39

>Users can make use of weird instructions.

If users can make use of any arbitrary "weird instruction", what
prevents the desired instruction set of a machine from being unbounded
above?  Eventually you have to choose *some* that you won't implement,
as a machine that implements every possible operation as a single
instruction is clearly unimplementable (few infinite items are
constructable in the real world :-)).

>Instead of insisting that they use the ill-conceived limitations of HLLs,

Are you truly certain that the only reason why the instruction in
question "fell out of use" is that it was due to Unisys "insisting that
[users] use the ill-conceived limitations of HLLs"?  I suspect that
ESPOL (or whatever the OS implementation language is called) will let
you get at just about any of those "weird instructions".  Perhaps no
user could come up with a *good* use for the instruction in question,
where "good" means "good enough to justify its inclusion in the
instruction set, to the exclusion of some other instruction that would
provide a greater performance improvement, or that would be more widely
usable."

>You will find that there are good applications uses of most of them.

Fine.  Show me a good application use of an instruction that, say, ORs
together the 15th bit of the 7th word following the word pointed to by
the operand and the 17th bit of the 9th word following that word and, if
the result is zero, rewinds the 12th tape drive on the machine - unless
the machine has no tape drives, in which case it prints the letter "Q"
on the console.  (No fair defining the application as being that very
operation!)

If you can't, then perhaps there are *some* "weird instructions" that
have no good application uses, and therefore, you do need some way of
choosing which "weird instructions" should go in anyway and which should
be deleted.  Perhaps a practical suggestion of exactly such a way might
have more effect on the designers of hardware and HLLs than a series of
complaints that they're just not doing things right with no real
suggestions as to how they might do them better?