for 64 bit long mode,

AMD vol2, 1.3.2 on page 15 says:



can someone give an example of how this is
used?

In Long mode, all immediates (when used for addresses) are sign extended 32bit values.

However this leads to a problem, where if you want an absolute memory address (since your limited to 32bit signed immediate), you're limited to 2GB from 0 -> 2GB. Not good. So AMD decided to have the offset be taken from RIP instead of 0, which allows you to access +-2GB using an immediate offset from the current code location.

The advantage in this is, most data is normally located with +-2GB of the code executing, (not within 0->2GB of memory), so it gives easy access to your data without requiring the use of a another register. The other added benefit, is that it make produced PIC (position independent code) easier as well, as long as your data is tightly coupled with your code.

do you mean that with the following code it isnt using
a 64 bit value for [xyz]





not if you were editting an uncompressed film in VM,

are you sure about this?

Thomas where are you?

Just when I was starting to think that long mode was good,

I think you can hack around this problem like so:


that will give you an absolute address above 32 bits,

ok, I've verified what you've said via fasm,

I assembled the following file:



and got the following fasm output:



and the hex looks like this:



so it is clearly not using absolute 64 bit addressing,

Note that although the x86 MMU implements a lot less than 64 bits
that the above is syntactically correct though it wont run as its
too big an address,

thats a CPU problem not a fasm problem!