NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9325

Text File | 1992-09-09 | 2.0 KB | 41 lines

Newsgroups: comp.arch
Path: sparky!uunet!email!mips.complang.tuwien.ac.at!anton
From: [e-mail] (Anton Martin Ertl)
Subject: Re: trapping speculative ops (LONG)
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: mips.complang.tuwien.ac.at
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 10 Sep 1992 08:04:46 GMT
Lines: 28

In article <[e-mail]>, [e-mail] (Lars Henrik Mathiesen) writes:
|> One would hope so. As a reality check, I looked at the 21064 data
|> sheet (it was handy). As far as I can see, destination conflicts do
|> stall the pipeline on that chip. Of course, currently, compilers have
|> no reason to write the same register twice without intervening reads,
|> so chip designers have no reason to build a preemption mechanism.

This is true in straight-line code, but generally a write to a
register is only redundant if *all* possible execution paths that
execute it write to the register another time before reading it.

|> I agree with the point raised by Anton Ertl, that trap bits on source
|> operands should not unconditionally cause a trap, but should propagate
|> to the result instead, because this allows the compiler to move a
|> greater part of an expression.

This is an interesting idea, but how do we know which instruction
caused the exception? Our solution is somewhat different. We check the
trap bit of the original trap-noting instruction. This means of course
that the compiler has to keep the trap bit alive, which restricts
register allocation, if the trap bit is associated with the
destination register. We did not discuss subroutines and interrupts,
but most solutions discussed here would be applicable.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed
[e-mail] Most things have to be believed to be seen