Why is the behavior of the repXX prefixes undefined for

Index > Main > Why is the behavior of the repXX prefixes undefined for

Goto page 1, 2 Next

Author

Thread

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

everything except the string instructions?

Are there any other instructions it behaves with consistently across processors? Or is it totally random?

_________________

25 Dec 2009, 11:23

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

'undefined' means just that, the manufactures do not guarantee what will happen either now, in the past, or in the future.

The P4 used repxx to help with branch prediction, I think, anyhow it was mostly useless anyway so not much to worry about.

Also, if you look closely at 'pause' it might look familiar.

What about SSE? Hmm, it seems to be used in quite a few places.

25 Dec 2009, 11:56

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

Thanks.

I'll try it with some SSE instructions and see if it works with any of them.

25 Dec 2009, 12:04

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

Look at the SSE instruction encodings. Do you see anything familiar in some if them?

25 Dec 2009, 12:08

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

Aww it's not that it works on them, it's that it is them. Sad

I was hoping for something cool like rep xchg [ecx],ecx lol

_________________

25 Dec 2009, 12:12

MazeGen

Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia

MazeGen

It is documented is undefined, but I believe all x86 processors executes it as a NOP (if it has not another meaning).

25 Dec 2009, 12:14

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

MazeGen wrote:

It is documented is undefined, but I believe all x86 processors executes it as a NOP (if it has not another meaning).

Which, of course, is dangerous to use and expect to get a nop. Since in the future Intel might decide to define something like 'rep mul eax' as a new instruction to do something else.

25 Dec 2009, 12:18

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

Why couldn't they make it work the same as on the string functions? What is the point of having another nop? Is it there purely to obfuscate code? :/

_________________

25 Dec 2009, 12:25

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

We don't know. You could try asking Intel if you really want to know.

But, I would guess that since it doesn't make sense to use rep on anything but string handling then it is good to leave it open for future expansion. Like they did with pause and SSE.

25 Dec 2009, 12:40

DOS386

Joined: 08 Dec 2006
Posts: 1901

DOS386

Azu wrote:

Why is the behavior of the repXX prefixes undefined foreverything except the string instructions?

I don't know

Code:

   rep ret
   rep ud2
   rep cmc
   rep pope cs
   rep nop

Answers (?) : [1] http://board.flatassembler.net/topic.php?p=106599#106599 [2] http://board.flatassembler.net/topic.php?t=6264

25 Dec 2009, 12:57

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4633
Location: Argentina

LocoDelAssembly

Well, AMD does document the use of "rep ret", doesn't it?

[edit]Oh yes, I've said that myself in DOS386's second reference Razz

[/edit]

Last edited by LocoDelAssembly on 25 Dec 2009, 22:42; edited 1 time in total

25 Dec 2009, 16:12

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

revolution wrote:

We don't know. You could try asking Intel if you really want to know.

I doubt they'd respond Razz

I figured someone here might know since it is a community about assembly.

revolution wrote:

But, I would guess that since it doesn't make sense to use rep on anything but string handling

Why wouldn't it make sense? It is loopXX but for one instruction and taking only one byte..

revolution wrote:

then it is good to leave it open for future expansion. Like they did with pause and SSE.

They could still use it for other instructions besides pause and SSE ones, though..

_________________

25 Dec 2009, 19:51

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

Azu,

Could you supply an example of useful prefixed instruction?

26 Dec 2009, 15:07

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

baldr wrote:

Azu,

Could you supply an example of useful prefixed instruction?

Any instructions you would use loop or loopXX on.

For example;

rep xor[address+ecx*4],imm/r

_________________

26 Dec 2009, 23:23

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

Azu wrote:

rep xor[address+ecx*4],imm/r

But how often is something like that needed? For the negligible benefit it provides would you be prepared to make other things like SSE implementation more complex?

26 Dec 2009, 23:43

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

revolution wrote:

Azu wrote:
rep xor[address+ecx*4],imm/r
But how often is something like that needed?

It was an example.

The prefix would be useful with almost any instruction.

revolution wrote:

For the negligible benefit it provides would you be prepared to make other things like SSE implementation more complex?

Why would it make SSE implementation more complex? The SSE instructions use it, but putting it in front of a normal instruction doesn't make it an SSE instructions. So why not implement it for normal instructions? I know it's too late to do this now, since they've already decided obviously, I just want to know what the reason could possibly have been. I'm curious like that.

_________________

26 Dec 2009, 23:47

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

The reason was given. It is of negligible benefit. The makers would have to add silicon and test vectors and whatnot to implement it. And they won't go to all that effort if the overall benefit is minor. Not many programs are in need of operations like that so they keep it open for other, more beneficial, uses in the future.

If rep was made universal at the start (the 8086) then current SSE would have been harder to implement. We are currently reaping the benefit of not being so liberal with rep.

26 Dec 2009, 23:56

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

But adding rep to an 8086 instruction doesn't turn it into an SSE instruction.. so I don't understand.. what would be the difficulty? And the silicon is already there for the string functions. Couldn't it be reused?

_________________

26 Dec 2009, 23:58

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system

revolution

If you enabled rep for everything then that means that SSE has to use some other encoding format because rep is already used.

And, no, silicon can't just be "reused" like that. CPUs don't work that way. Read some books about CPU design if you want to know how they do work.

27 Dec 2009, 00:12

Azu

Joined: 16 Dec 2008
Posts: 1160

Azu

revolution wrote:

If you enabled rep for everything then that means that SSE has to use some other encoding format because rep is already used.

Azu wrote:

They could still use it for other instructions besides pause and SSE ones, though..

revolution wrote:

And, no, silicon can't just be "reused" like that. CPUs don't work that way. Read some books about CPU design if you want to know how they do work.

Does the 16bit prefix need extra silicon for each individual instruction too, then?

_________________

27 Dec 2009, 00:17

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum