LINUX.ORG.RU

x86-64 - размер указателя


0

0

уважаемые, пожалуйста, почитайте таки вечерком на досуге Intel 64 and IA-32 Architectures - Software Developer Manual в связке с System V Application Binary Interface AMD64 Architecture Processor Supplement и постарайтесь не делать столь распространённой ошибки утверждая, что «на 64х битной системе указатель имеет размер 8 байт». это попросту не так в силу того, что 99% адресации в вашем исполняемом - косвенная относительно базы.

ps: да, я на 100% уверен, что 99.9% авторов в этом разделе никогда не видели и не трогали 64х битных архитектур, отличных от x86-64 (и не надо!). так что отсылка к спаркам или итаниумам & K будет явно не в кассу.

#include <stdlib.h>

struct node {
    void *next;
    int data;
};

struct node *
foo(void)
{
    struct node *head = 0;
    int i;
    for (i = 0; i < 0x1234; i++) {
        struct node *n = malloc(sizeof(*n));
        n->data = i;
        n->next = head;
        head = n;
    }

    return head;
}

$ cc -c -Wall -Werror -O2 test.c
$ objdump -d test.o

test.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <foo>:
   0:   55                      push   %rbp
   1:   bf 10 00 00 00          mov    $0x10,%edi
   6:   53                      push   %rbx
   7:   bb 01 00 00 00          mov    $0x1,%ebx
   c:   48 83 ec 08             sub    $0x8,%rsp
  10:   e8 00 00 00 00          callq  15 <foo+0x15>
  15:   c7 40 08 00 00 00 00    movl   $0x0,0x8(%rax)
  1c:   48 c7 00 00 00 00 00    movq   $0x0,(%rax)
  23:   48 89 c5                mov    %rax,%rbp
  26:   bf 10 00 00 00          mov    $0x10,%edi
  2b:   e8 00 00 00 00          callq  30 <foo+0x30>
  30:   89 58 08                mov    %ebx,0x8(%rax)
  33:   83 c3 01                add    $0x1,%ebx
  36:   48 89 28                mov    %rbp,(%rax)
  39:   81 fb 34 12 00 00       cmp    $0x1234,%ebx
  3f:   48 89 c5                mov    %rax,%rbp
  42:   75 e2                   jne    26 <foo+0x26>
  44:   48 83 c4 08             add    $0x8,%rsp
  48:   5b                      pop    %rbx
  49:   5d                      pop    %rbp
  4a:   c3                      retq

// wbr


впрочем, одно маленькое уточнение: это естественно касается адресов ф-й т.е. callq <xxx>. с точки зрения данных [то, что вернется из malloc() выше и вообще указатели в .data/etc] будет 64х битным.

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от dilmah

> А ты знаешь, какой процент негров в США?

на вскидку не помню. но найти, думаю, не есть большая проблема. не так давно [в пределах года] мне попадался на глаза большой и толстый официальный документ, составленный по материалам исследований их грубо говоря ФМС о расовом распределении в США. забавный документ, хотя и трудно читабельный.

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от klalafuda

[off] не, ну тут самый интерес в "сказать на вскидку".

Просто, большинство людей называют 30-40 процентов, что в несколько раз выше реального. [/off]

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

> [off] не, ну тут самый интерес в "сказать на вскидку". Просто, большинство людей называют 30-40 процентов, что в несколько раз выше реального. [/off]

ну если бы я там жил причём достаточно долго, то может быть и сказал бы. или хотя бы активно интересовался их внутренними проблемами. а так - с какой стати.

// wbr

klalafuda ★☆☆
() автор топика

> то попросту не так в силу того, что 99% адресации в вашем исполняемом - косвенная относительно базы.

Кого это волнует вообще? Может еще и short jmp вспомним? Собственно код занимает лишь малую часть используемой памяти.

А вот данные распухают как положено. Ибо хоть усрись, но sizeof(void*) - 8. И sizeof(void(*)(void)) тоже 8.

anonymous
()

По сабжу - ничего не понял. sizeof(void *) всегда 8 на 64-бит системе, так? Тогда почему "на 64х битной системе указатель имеет размер 8 байт" - ошибка? Раскрой тему.

tailgunner ★★★★★
()

И как это отменяет тот факт, что указатель 64-битный?

>ps: да, я на 100% уверен, что 99.9% авторов в этом разделе никогда не видели и не трогали 64х битных архитектур, отличных от x86-64 (и не надо!). так что отсылка к спаркам или итаниумам & K будет явно не в кассу.

На спарках такая модель адресации тоже употребляется исключительно часто, на альфе - вообще почти только она (неявно относительно регистра gp). Про итаниум не скажу, но не суть.

anonymous
()
Ответ на: комментарий от tailgunner

> 13% вроде (это без Вики). Правильно? :)

AFAIU сильно зависит от того, где конкретно. ну к примеру сравнить Сан-Франциско, Нью Йорк и что-нить на Аляске - будут совершенно разные картины. а так, усреднёно по больнице - IMHO не очень интересно. по крайней мере с практической точки зрения. вот приезжаешь ты в NY и видишь, что ну ёмаё! ну ни разу не 13 а все 25% :) или наоборот, приезжаешь в какую-нить деревню Санивейл в CA и удивляешься мол хде ж они эти негры то?! нету их. ну почти нету.

ps: нет, самолично не сравнивал. скорее, базируюсь на рассказах коллег, которые туда периодически мотаются :) так что может быть на самом деле распределение и другое.

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от klalafuda

>>13% вроде (это без Вики). Правильно? :)

> AFAIU сильно зависит от того, где конкретно. ну к примеру сравнить Сан-Франциско, Нью Йорк и что-нить на Аляске

Вопрос ставился однозначно - "в США". То есть средняя темепература по больнице.

Да хрен с этими ниггерами, в чем ошибка с 8-байтовыми указателями?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Да хрен с этими ниггерами, в чем ошибка с 8-байтовыми указателями?

да ни в чём ни в чём, relax :) с точки зрения данных [что в основном и интересно] он честный 64bit.

ps: это обычные глюки. у меня. меньше нужно во всяком ужасе копаться.

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от klalafuda

Эм, а можно по-подробнее для самых маленьких? :)

Всё дело в косвенной адресации и position independ коде? Т.е. на самом деле в определённых случаях 8-байтный указатель используется "неполностью"(только часть байт)?

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.