🚀 go-pugleaf

In article <1991May7.195932.8770@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes:
>gary@clipper.ingr.com (Gary Oblock) writes:
>
>>Come ON guys!
>>
>>So far only two people have sent me any information. I've also seen
>>one posting on the subject. I could have sworn that John Mashey would
>>have something to say about the wisdom of this feature in a RISC
>>processor. Doesn't anyone like David Wall or John Hennessy (there was
>>nothing relevant in Hennessy & Patterson) read this group??
>
>
>It's not too hard to imagine a simple study (give the right tools).
>If you've got a 3-address machine, measure a bunch of code.
>Then, mark the arithmetic instructions as 2-address
>instead of 3-address (pretty dependent on the particular compiler),
>and hack the necessary code that tries to take advantage of
>2-address instructions.  (Chaitin talks about how to modify
>his allocator to handle 2-address instructions).
>Then measure the same bunch of code (speed and size).
>
>This won't help you with understanding the benefits of 2-address
>instructions (all those extra register addressing bits),
>but it will show the costs (extra move instructions).
>
>Then publish the results.
>
>Preston Briggs

Several years ago (longer than I'd like to think), my dissertation did an
analysis of the efficiency of different instruction set styles in representing
programs.  The analysis looked at how closely the instruction set could
represent the intent of the program without adding unnecessary work.
The analysis follows the line of thinking proposed above by Briggs.

The results showed that pure 3-address machines (ones without 2-address
abbreviated forms) tended to have needless information.  Most programs
do not require three address instructions.  Pure 2-address machines were
much better than pure 3-address ones -- occasionally a 2-address machine will
need to have a 'useless' instruction just to get the arithmetic done, but it
is seldom.

The NTIC should have it.  It was done at UCSD in 1986, title "The Evaluation
of Instruction Sets for Language-Orientd Instruction Set Computers".

John Van Zandt
-------------------------------------------------------------------------
E-mail: johnv@sequent.com
V-mail: (503) 578-3136
P-mail: Sequent Computer Systems, 15450 SW Koll Pkwy, Beaverton, OR 97006


-- 
John Van Zandt
-------------------------------------------------------------------------
E-mail: johnv@sequent.com
V-mail: (503) 578-3136
P-mail: Sequent Computer Systems, 15450 SW Koll Pkwy, Beaverton, OR 97006