News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

REX prefixes & default Operand size

Started by Rainstorm, June 22, 2008, 07:10:39 AM

Previous topic - Next topic

Rainstorm

Hi.

I don't know much about this stuff, & haven't tried out any 64bit code since i don't have a 64bit OS.

in the intel Manual it says
Quote64-bit mode is enabled by the operating system on a code-segment basis. Its default
address size is 64 bits and its default operand size is 32 bits. The default operand size can
be overridden on an instruction-by-instruction basis using a REX opcode prefix in
conjunction with an operand size override prefix.
REX prefixes allow a 64-bit operand to be specified when operating in 64-bit mode.

2 questions

1) why is the default operand size set at 32 bits in 64bit mode ?

2) why do you need the REX prefix to do 64 bit stuff in 64bit mode ?
    if anything....... seems logical that the prefix should be to switch in order to do 32 bit stuff (when 
    running in 64 bit mode)

The whole thing just seems a little irritating

they later say
QuoteBy
using this mechanism, many existing instructions have been promoted to allow the use of
64-bit registers and 64-bit addresses.
...... still don't get agood picture as to why though

THanks.
- - - - - - -

MazeGen

Why? Ask AMD64 developers ;-)

It can be irritating, but it is a matter of fact :)

Quote from: Rainstorm on June 22, 2008, 07:10:39 AM
they later say
QuoteBy
using this mechanism, many existing instructions have been promoted to allow the use of
64-bit registers and 64-bit addresses.
...... still don't get agood picture as to why though

They mean that MOVSD was promoted to MOVSQ, MOVSX to MOVSXD and so on...

Rainstorm

Mazegen, thx for answering : )

am learning 32 bit assembly now,...so maybe i could skip the 64bit pahse & learn 128 bit lol!!... when it gets here.
maybe by that time 128 bit will be around

btw........ is 128 bit very far away ? wonder what that will be like

i get the urge now & then to try 64bit code but don't have a 64bit windows os.

Mark Jones

I think we might be experiencing a logarithmic scale in terms of processor radix versus time... i.e., 8-bit mainstream PC's lasted for almost no time at all, then 16-bit came along and lasted a few years, then 32-bit came along and has been the primarily platform for the past decade or so... and now 64-bit has came out -- with little fanfare. This time, the latest processor offering is being accepted much slower than any predecessors. Part of this I feel, is because there is little [specific] benefit to moving to 64-bit, and 64-bit apps require between 3x and 4x the amount of RAM and system resources to run. Combine that with a more complicated mnemonic encoding and calling convention, and you get very few assembly language programmers brave enough to try coding in it. :P
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

Rockoon

Its just a simple economy-of-scale thing happening.

Even in 64-bit mode you will most often be using 32-bit data simply because its good enough. Requiring a prefix to access memory in 32-bit pieces would add a lot of bytes to your code (and thus, reduce instruction decode efficiency)

Essentialy, under x86-64 the native wordsize is still 32-bit, while native pointer are a mix of 64-bit and 32-bit (RIP-relative)

IA32 had a similar programmable mode of operation for native wordsize. Both 16-bit and 32-bit code could default to EITHER 16-bit or 32-bit registers, with the size override prefix simpy toggling to the non-default size. Under DOS if you used your own extender you were free to choose which default you wanted, while under windows the OS has made the choice for you (32-bit default in flat mode, 16-bit default in v86 mode)

The entire "64-bit" thing is more about addressing than anything else, and technically we are at 48-bit addressing (hard limit under current AMD64 CPU's) and Win64 actualy limits this to 44-bit addressing, with most motherboard chipsets currently only paying attention to 36 bits.

For most ASM developers, the main benefit of 64-bit mode is the extra registers (8 more general purpose, 8 more SSE) although the extra size of the GP's can also come in handy. It would have been nice if AMD and Intel got together and pushed for a new standard for register naming instead of the crazy situation we are now in. I realize that developers of new assezmbler are free to name them watever they want, but really this sort of change requires backing by the big boys.
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

Rainstorm

Rockoon,

thx..do not know much of this stuff & your post was very enlightening.

rockoon wrote >>
QuoteFor most ASM developers, the main benefit of 64-bit mode is the extra registers (8 more general purpose, 8 more SSE) although the extra size of the GP's can also come in handy.
...the extra registers is the part that excites me the most & is the main motivation for me wanting to try it. - I haven't tried any 64bit code yet - am not gonna be getting vista.. so dunno when i'll be able to dip my finger in it ; P - i should try & get a copy of a 64bit winxp maybe.

thankyou.