Вопрос про стэк и таблицу строк

Тема в разделе "WASM.BEGINNERS", создана пользователем Antolflash, 18 янв 2010.

  1. maksim_

    maksim_ New Member

    Публикаций:
    0
    Регистрация:
    15 июл 2009
    Сообщения:
    263
    что касается копирования в стек - напиши
    Код (Text):
    1. static const char s[] = "123"
     
  2. Rockphorr

    Rockphorr Well-Known Member

    Публикаций:
    0
    Регистрация:
    9 июн 2004
    Сообщения:
    2.615
    Адрес:
    Russia
    короче дожили - скоро
    Код (Text):
    1. mov EAX,offset(mylabel)
    2. mov EIP,EAX
    будут рекомендовать вместо джампов - быстрее видете-ли :)
     
  3. Ustus

    Ustus New Member

    Публикаций:
    0
    Регистрация:
    8 авг 2005
    Сообщения:
    834
    Адрес:
    Харьков
    maksim_
    еще как может...
     
  4. defaultplayer

    defaultplayer New Member

    Публикаций:
    0
    Регистрация:
    18 июн 2006
    Сообщения:
    214
    нет такой инструкции :)
     
  5. maksim_

    maksim_ New Member

    Публикаций:
    0
    Регистрация:
    15 июл 2009
    Сообщения:
    263
    есть в x64.

    я предположил. вот только не понятно - как может, если подряд идут несколько пушей, ведь адрес стека ещё неизвестен..?
     
  6. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    Реально (из x86) только AMD 10h (Phenom и т.п.) могут, т.к. для этого кроме stack engine еще и соотв.поддержка со стороны исп.блоков и подсистемы памяти должна быть, а у Intel по традиции юзается только по одному блоку store и load, и соотв-но любые сохранения, в т.ч. и через mov, выполняются по 1 за такт

    maksim_
    Смотрим в книгу, видим ... ? ;)
    См. про stack engine - кратенько в #19, подробнее у А.Фога в microarchitecture.pdf или манулах Intel и AMD
     
  7. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    leo
    Из каких соображений тогда в optimization reference указана латентность и пропускаемость mov в полтакта?
     
  8. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    leo
    Или это распространяется только на non-memory операнды? Явно там об этом вроде как не указано, если не считать секцию C.3.3, где тоже ничего особо конкретного не говорится.
     
  9. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    Из таких, что это раздел Latency and Throughput with Register Operands :)
    А насчет memory нужно смотреть Chapter 2 в разделах Issue Ports and Execution Units + Load and Stores
     
  10. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    maksim_
    В 64битном режиме тоже нет. Появилась адресация относительно rip, но сам rip меняется только с помощью call/jmp/Jcc/etc.
     
  11. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    leo
    Да-да. Увидел. Спасибо. Во всех архитектурах по одному load/store за такт.
     
  12. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    *максимум по одному load/store за такт.
     
  13. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    Именно то самое в книге и вижу. :)
     
  14. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    А планирование можно не учитывать ?
     
  15. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    Clerk
    А с чего его нужно учитывать? Не было речи даже о том, присутствует ли ОС вообще. А то так можно ещё и сторожевую страницу вспомнить, а потом ещё и про обычный PF... а то вдруг странички нету в физической памяти... да куча ещё может быть факторов, которые в данном контексте неинтересны.
     
  16. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    l_inc
    Тоесть код в сферическом вакууме.. На практике толку от вашей оптимизации нет.
     
  17. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    Clerk
    Разумеется есть.
    Во-первых, осутствие ОС — это нифига не сферический вакуум, а во многих случаях вполне штатная ситуация. Начальные этапы загрузки ОС тоже надо оптимизировать. Или даже простое исполнение на Dispatch Level — это большая редкость?
    Во-вторых, даже в условиях планирования переключение контекста происходит одно на миллион инструкций свободного пробега потока. И если нужно оптимизировать цикл, содержащий обращения к памяти, с десятком тысяч итераций на тик таймера, то от планирования технике оптимизации ни холодно, ни жарко: что оно есть, что его нет, оптимизировать одинаково.
     
  18. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    l_inc
    Ога, вот только сколько поток простаивать будет когда прервётся не учли ?
    От оптимизации лодер быстрее работать не будет, железо сдерживает, жёсткий диск например. А стек - хочешь не хочешь а юзать придётся.
     
  19. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    Clerk
    Я понимаю, что хочется поговорить. :) А мне и не жалко.
    А кому какая разница, сколько он будет простаивать? Ещё раз: оптимизировать о-ди-на-ко-во (или у Вас есть конкретные предложения, как приугробить систему, отъедая от чужих квантов?). Это во-первых.
    Во-вторых в условиях планирования абсолютное время неинтересно по определению. Интересно то, сколько тактов понадобится конкретному потоку на решение его личных проблем.
     
  20. green

    green New Member

    Публикаций:
    0
    Регистрация:
    15 июл 2003
    Сообщения:
    1.217
    Адрес:
    Ukraine
    Clerk
    Вы почему-то каждую задачу стремитесь рассматривать в контексте специфических механизмов операционной системы. Такая модель во многих случаях излишне сложна. :derisive:
    Например, в данном случае IMHO достаточно учесть влияние планировщика и своппинга, как варьирование производительности оперативной памяти.