CPUID

А за счет чего она станет меньше? Можно на пальцах В секции днанных например я размещу 10 байт данных или в секции кода размещу 10 байт данных. Как будет это влиять на размер?
А за счет чего она станет медленней?

(прошу прощения за совсем детские вопросы, просто ветки ниже BEGINNERS ничего нет)

 

Mikl___ с размером понял. А вот со скоростью... может еще рановато заострять на этом внимание?

 

Про скорость я читал в Intel Software Optimization Reference (надеюсь правильно написАл).

 

Продолжаю копать дальше. Чем дальше копаю тем более непонятно.
1. почему неинициализированные данные

Code (Text):

1. .data?
2. mesbox_text db 600h dup(?)

у меня в коде:

Code (Text):

1. .386
2. .model flat,stdcall
3. .data?
4. m db 10000h dup(?)
5. .code
6. start:  
7. nop
8. end start

отображаются в дампе, а у Mikl___а в коде? Чую ну очень идиотский вопрос, ну уж простите - учусь

До конца не понимаю механизма работы. Как в отладчике работает понимаю, но сам бы не додумался и не повторил бы...
Как это работает:

Code (Text):

1. mov edi,offset mesbox_text
2. mov esi,offset buffer
3. mov [esi+11],ebx
4. mov [esi+15],edx
5. mov [esi+19],ecx

Напишите пожалуйста коменты к этим строчкам и вызываемой процедуре StringOut.

 

Shoorup
Неинициализированные данные (в данном случае под неинициализированными данными понимаются те, при указании которых ставится знак "?") могут как отображаться, так и не отображаться в дампе, находясь в любой секции.
1) Если неинициализированные данные находятся в конце секции (не важно, какой), то самым логичным поведением компилятора было бы увеличение атрибута секции VirtualSize при неизменном атрибуте SizeOfRawData. Т.о. на размер образа на диске такие неинициализированные данные не повлияют, но при загрузке образа в память, необходимый объём памяти будет выделен.
2) Если Вы вдруг захотите после инициализированных данных впихнуть инициализированные. Т.е примерно так:
section '.data' data readable writeable
uninitData db 1000 dup ?
initData db 'ю'
, то компилятор будет вынужден заполнить промежуток реально существующими данными. И тогда такие "неинициализированные данные" на самом деле будут находиться в образе на диске. И инициализированы они будут нулями. Опять таки это независимо от того, в какой секции они находятся.

Всё выше сказанное относится к fasm, но может быть перенесено и на masm с учётом того, что masm несколько ограничивает программисту свободу выбора. ИМХО fasm демонстрирует более истинную картину.

 

Code (Text):

1. StringOut       proc
2. a1:     lodsb ;загружаем символ из [esi] в al и увеличиваем esi
3.         or al,al ; если al равен 0
4.         jz a2 ; то выход
5.         stosb ;копируем символ в [edi] и увеличиваем edi
6.         loop a1 ;уменьшаем ecx, если не равен 0, то повторяем итерацию
7. a2:     retn
8. StringOut       endp

Эта процедура копирует нульзавершённую строку из [esi] в [edi] длиной не более чем ecx. Некий аналог lstrcpy из kernel32.dll.

 

Интерестно с loop получается в счетчике лежит огромное число. А почему тут не jmp a1?

 

Shoorup
имхо, вобще что-то не то...

наверно надо что-то вроде

Code (Text):

1. LODSB
2. STOSB
3. TEST AL, AL
4. LOOPNZ a1

 

K10 ноль занесешь тогда.
LODSB; загружаем
STOSB; копируем
TEST AL, AL; проверяем
LOOPNZ a1; переходим если не ноль
А если ноль то мы его занесем и выйдем из процедуры. Или я не правильно понял?

 

Shoorup
Ага, завершающий ноль же тоже нужен...
Ну и в ECX максимальный размер.
Либо можно немного переделать и по ЕСХ определять количество скопированных байт если нужно, но тогда максимального размера не будет.

 

Я так понимаю, что все строки выводятся в мессбокс. А как происходит переход на следующую строку?
Частоту процессора определяют по rdtsc? Или я опять не туда смотрю?

 

db 0Ah

Там просто замеряется сколько тактов пройдёт за 1000 миллисекунд (герц - это количество тактов в секунду, в секунде 1000 миллисекунд).

Code (Text):

1. mov TimerLo,eax
2. mov TimerHi,edx
3. push 1000                     ; DelayTime=1000
4. call _imp__Sleep@4         ; Sleep(DelayTime);
5. rdtsc
6. sub eax,TimerLo
7. sbb edx,TimerHi
8. mov TimerLo,eax
9. mov TimerHi,edx

 

Не могу понять почему в один и тот же выделенный размер (как мне кажется) компилятор отказывается заносить содержимое регистров?
Вот так:

Code (Text):

1. .data
2. CPU_Vender dd 3 dup(?)
3. String_null db 0
4. .code
5. start:
6. ...
7. mov CPU_Vender, ebx
8. mov CPU_Vender+4, edx
9. mov CPU_Vender+8, ecx

нормуль все, но если пытаюсь поменять
CPU_Vender dd 3 dup(?) на CPU_Vender db 12 dup(?) , компилятор почему то ругается на 3 строчки с movами. Почему?

В принципе понимаю, что для строчки достаточно 12 байт. Так dd 3 dup(?) создаю 3 раза по 4 байта (двойному слову), и так db 12 dup(?) создаю 12 байт по байту. Так какая разница как я выделил память?

 

Как всегда спасибо Mikl___ Единственное для себя не уяснил один момент - или где-то не дочитал или нет нигде такого: есть ли раличие в хранении данных в памяти? Запишу я слово в память или 2 байта - есть ли разница?

 

Shoorup
Канешна есть. Почитай про big endian && little endian

 

Всеравно не очень догоняю... уж не бейте за "жирафа"...
Получается для х86 идет little-endian или "от младшего к старшему". Я выделяю и в первом и во втором случае место 12 байт. Процессор будет заносить содержимое регистров в эту область по "правилу от младшего к старшему" Какая разница как я выделил память? Почему во втором случае мне нужно переопределять dword ptr ?