Re: RFC: RIP relative adresses


<rhyde@xxxxxxxxxx> wrote in message
news:1177713618.622737.286570@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 27, 2:24 pm, "cr88192" <cr88...@xxxxxxxxxxxxxxxxxx> wrote:
just figured, maybe a few people can offer comments here:
some assemblers apparently make RIP-relative addressing the default in
long-mode, and others making absolute the default.

There is a common saying in computer science: "Optimize for the most
common case".
Now just what "optimal" means in this case is a good question. If
you're trying to minimize typing, for example, I'd go with the mode
that is used most often as the one that get the plain ID.


sadly, I am not entirely certain whether ABS or RIP addresses will be used
more often.

however, I am thinking RIP-rel addressing may be better as a general rule
(shorter opcode encoding, less often requiring a reloc, ...).


Suppose you're trying to optimize readability. Given that all the
existing code uses an unadorned label as an absolute address, it makes
sense to keep that scheme for 64-bit code, so that people won't get
confused when switching between 32-bit code and 64-bit code.


yes.

these were my thoughts, which is why I had considered sticking to a
[rip+label] or [$label] based convention for rip-rel addrs.

however, for basic uses, behavior should be exactly the same (the main
difference being that using rel addressing, by defalt, one will have PIC, or
at least far less relocs for the linker to worry about).

actually, the main difference would be in the creation of PIC code (ABS code
shouldn't need to worry much either way).

where for abs code, we would do (either way):
mov eax, [array+rcx*4]

wheras for pic, one would need to do something like:
lea rdx, [rip+array] ;abs
mov eax, [rdx+rcx*4]

lea rdx, [array] ;rel
mov eax, [rdx+rcx*4]



(it seems a few other assemblers, including gas, do it this way).

Be careful about using Gas (AT&T syntax?) as your model. Often, I've
found that syntactical additions to Gas have been motivated more by a
desire to make the changes to the assembler easy rather than being
based on some global overriding principle.


yes, that is true.

well, what it seems thus far (info skimmed online):
masm makes RIP the default, as do goasm, fasm, ...
gas and nasm-64 (I guess), seems to make ABS the default (and from what I
say, part of some xml-based forum log, uses a completely bizarre syntax for
RIP adressing).



mov rax, [#foo]
defaults to ABS (#, @, ... seem possible). likewise, I could overload '$'
here, but this is counterintuitive.

If you go this route, I would recommend "@". "AT <address>" sounds
more like an absolute address to me than the other alternatives.


yes, this makes sense.




note: in my case addresses given explicitly would always be ABS, ie:
mov [0xB8000], rax
mov [0xB8008], rcx
mov [0xB8010], rdx

No. I'd use whatever scheme you decide for symbolic addresses. If the
default becomes RIP, then require the "@" (or whatever) in front of
the numbers. Consistency is very important. Then again, that's also an
argument for making absolute address the default anyway (as it's more
consistent with the 32-bit modes).


MASM made addresses of this form relative, I guess to the major complaint of
the person writing some of the pages I was looking at.

usually, if someone specifies a raw number like this, I will assume they are
referencing some fixed area of memory.

my thought is that a sign could be required for relative numbers, ie:
mov rax, [+512]
mov rcx, [-0x1000]

if such a thing makes much of any real sense at all.



what I am currently leaning twards is this:
simple mem accesses are relative by default;
absolute references are explicit, via @;
numerical addresses are absolute by default;
the rip+label form is still valid, but technically redundant.

otherwise, it may make sense to split my modrm function into 32 and 64 bit
versions, in order to reduce the amount of tweaky edge-case flags
checking...


right now, I can imagine a few alterations which in an ideal/fantasy world
would make x86-64 more useful. simplest being some way of allowing REX
prefixes in 16/32 bit code, less simple being merging rex, modrm, and sib
into a single structure in place of the old structure (ie, as a kind of
"super-modrm").


oh well...


hLater,
Randy Hyde



.

Relevant Pages

  • Re: ///Re: NASM problem
    ... absolute address at compile time (by specifying this directly in the PE ... NASM, if it's producing an absolute binary file, ... harking back from the days when assemblers ... mov ax, label_1 shr 16 ...
    (alt.lang.asm)
  • Re: Nasm 0.99.01 available
    ... Herbert Kleebauer wrote: ... there are pretty much three ways to encode ... mov eax, ... where xxx is an absolute address. ...
    (alt.lang.asm)
  • Re: Nasm 0.99.01 available
    ... Frank Kotler wrote: ... there are pretty much three ways to encode ... mov eax, ... where xxx is an absolute address. ...
    (alt.lang.asm)