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

Internet Message Format | 1992-09-08 | 2.7 KB

Path: sparky!uunet!mcsun!sunic!dkuug!diku!thorinn
From: [e-mail] (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops (LONG)
Message-ID: <[e-mail]>
Date: 9 Sep 92 12:17:01 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Department of Computer Science, U of Copenhagen
Lines: 44

[e-mail] (Stanley T.H. Chow) writes:
>We must handle the cases where a speculative load into a caller-save
>register is not finished by the time the subroutine wants to write
>into that register (I assume the old operation is discarded and the
>new write goes into the pipeline rightaway).

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.

>Given that we want to scoreboard the trap-bits, I suggest the simple
>solution is to have a new instruction that saves a single register
>(both content and trap-bit) into two words.

A more radical solution: Put the flags in the memory system! Given a
CPU/memory interface that only supports aligned 64-bit register loads
and stores (not too far from some current RISCs), it would be easy to
add some extra bits to both registers and memory words. This looks
very much like earlier tagged architectures, except that the extra
information is the history of a value instead of its type.

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 also solves the subroutine problem
--- register saves do not trap.

As a further elaboration, the single trap bit might be extended into
several ``status'' bits, such as carry and overflow for integer
registers, and inexact, overflow, and so on for floating point. The
compiler could then generate an instruction to branch/trap to an error
handler on exactly those bits that the language semantics indicate.

If zero and negative flags are added, the test instruction turns into
a general conditional branch mechanism. And to please the LISP people,
we could add one or two user defined flag bits.

On super-scalar processors, it should be possible to let the test
instructions issue in parallel with almost anything else, so that they
can be hidden in the latency of arithmetic instructions.

Lars Mathiesen (U of Copenhagen CS Dep) <[e-mail]> (Humour NOT marked)