[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] branch system
- To: f-cpu@seul.org
- Subject: Re: [f-cpu] branch system
- From: Yann Guidon <whygee@f-cpu.org>
- Date: Sun, 01 Jul 2001 01:14:11 +0200
- Delivery-Date: Sat, 30 Jun 2001 19:16:19 -0400
- Organization: http://www.f-cpu.org
- References: <200106271029.188a@lh00.opsion.fr> <15GO9I-0pdtTcC@fwd00.sul.t-online.com>
- Reply-To: f-cpu@seul.org
- Sender: owner-f-cpu@seul.org
hi !
Reichelt wrote:
> nicolas.boulay@ifrance.com schrieb:
<snip>
> Long time ago, there was an idea use to the rightmost 2 bits of the jump address
> as prediction bits.
note :
the jmpa instruction has the bits 8 and 9 free :
they are reserved for storing static branch hints.
their behaviour is undefined yet.
so you see, we've thought about this problem long ago :-)
> Since instructions are aligned to 4-byte-boundaries the two rightmost bits are
> zero by definition. These bits are free to store prediction bits. The compiler
> has a harder job, because the prediction bits are not in the jump instruction,
yes, there is a dedicated field.
> but in the addresses in a jump table. The idea was even to change the bits
> according to the last branch taken or not.
that is something desirable and possible : since all registers
are read speculatively, the value of the jump register can be read,
modified and written back. "We just have to do it".
> This has the strange consequence that a jump (Reg13) changes the content of
> Reg13. You can use it for jumping again, but you can not read the first byte of
> the instruction word via Reg13.
if you want to read this word, you know that you have to mask (if this scheme
is remembered to be written in the manual). however, this is a desirable
side effect that the register changes : the value of the predictor can be
kept along with a program's context when there is a task switch.
and that is good :-)
> But that is just strange, not a real problem. The only use I can imagine
> for doing that (reading bytes which were a branch target before) is
> self-modifing code, and that is considered EVIL anyhow. All well-behaved
> programs know to keep the data pointers and code pointers separate.
yup, but sometimes it can be either useful or necessary.
when this happens, at least, we have to know the consequences.
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PS: i have been mute some time, while i was "updating" my PC's configuration :
Duron 800MHz, 288MB SDRAM, a new 30GB HDD, a dual-head Matrox card, a
new modem... if you can read this, it means that the modem works but i still
have to partition the HDD in a stable way for W95/FAT16...
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/