68k instruction fetch pipeline ? - Page 1

Hello, I'm here with my annoying questions again.

Today, I'd like to have a little bit of light casted to my knowledge of the 68k intruction pipeline.
That is, I'm wondering how to write self-modifying code that won't get ignored by the processor.
Have a look à this code sample :

	lea %pc@(instruction),%a0
	addq.w #1,%a0@
instruction:
	moveq #0,%d0

(Yes, I know, I could have done the incrementation in one instruction, but I did not feel so inclined)

It does not seems to do what one would expect (that is, set d0 to 1). Is this due to an instruction fetch pipeline of some sort ?
And, if yes, how long is it, and how can I force it to get invalidated so that the modified code is executed ?

If I remember well, the 68k uses a 4 bytes instructions prefetching, ie it pre-loads the next 4 bytes of instructions.
The fetching buffer is flushed after a branch operation, that's why those are slower (they can't use prefetching).

Hmm, ok. So if I add, say, two nops between the add and the modified instruction, it should work as expected ?
Hmm ok, I try that.

It works!

Thanks, Ximoon.

Ximoon
: If I remember well, the 68k uses a 4 bytes instructions prefetching, ie it pre-loads the next 4 bytes of instructions.

It seems to be a bit more complicated according to the test I made some times ago : http://membres.lycos.fr/extended/pipeline.txt (sorry, it's written in French but I can translate it).

ExtendeD > Welcome

Thx
Hoping this place will soon attract the international community.

./5> . If you are sure of this, it is quite funny. I am wondering about a few things however :

- For the move.? #imm,patch you do not say whether it is a word or a long absolute addressing mode. I think this is relevant since it affects the length of the binary code for this instruction.

- How do you test this ? I have an idea but there are a few things that could go wrong with it.

ExtendeD :
Thx
Hoping this place will soon attract the international community.

Hoping the contrary... As if the community wasn't already fragmented enough!

But there is only one other "big" english forum, TICT's one, which is quite slow and has many ads and popups

If you want to continue this discussion, please do it in another topic (or on IRC), we're off-topic here.

There is also TI's one: http://www-s.ti.com/cgi-bin/discuss/sdbmessage.cgi?databasetoopen=calculators.

And the TICT one works fine. We all know your "which is quite slow and has many ads and popups" is just an excuse, the real reason you open a competing board is because you don't like us.

Vertyos
: If you want to continue this discussion, please do it in another topic (or on IRC), we're off-topic here.

Last warn. Have you read this thread's title ?

This is not the subject I intended for this topic, as the title says.
For now I am waiting for ExtendeD's reply and I would like this interesting discussion not to be flooded with posts that have nothing to do with it.

As Vertyos said, "If you want to continue this discussion, please do it in another topic (or on IRC), we're off-topic here."
I'd prefer not to have to kick you off this topic since you may have interesting things to say. But I will surely do so if needed.
Thanks.

[edit: crossed with previous post]

I don't remember exactly the test case I used 2 years ago to get those results, but the snippet was something like this (for move.b dn,(an) here):
s

 lea patch+1(pc),a0
  clr.b (a0) ; initialize
  moveq #-1,d0 ; what we want to write
  move.b d0,(a0) ; instruction tested
patch:
; nop ; <<insert nops sequences here>>
  moveq #0,d0
  move.l d0,($4C00).w ; display the result
  rt

-> Without the nop, a white line in the top left-hand corner of the screen.
-> With the nop, a black line.
==> 2 bytes (1 * sizeof nop) are prefetched.

I have re-tested a few instructions of the pipeline.txt, the results tally.
Here are results for other instructions:

instruction ---- bytes prefetched
move.b d0,patch         2
move.b #imm,patch       2
move.b d0,(a0)          2

Maybe this depends on the instructions timings / complexity ?
I mean, when executing fast instructions, the pipeline may not have time enough to fill up.

spectras
: - For the move.? #imm,patch you do not say whether it is a word or a long absolute addressing mode. I think this is relevant since it affects the length of the binary code for this instruction.

Yes, you are right. I have only tested long absolute mode.

spectras
: I mean, when executing fast instructions, the pipeline may not have time enough to fill up.

Yes, and perhaps on the size of the instruction, and whether it needs to fetch data (for clr, move #imm, ...)