Masm, nasm, fasm, hla, краткий ликбез?

) Я так и думал что ктото придерется именно к этому слову, ну ну

 

Где в FASM аналог секции .data?
Почему
section '.bss' data readable writeable
без предупреждения становится инициализированной, если в неё попали инициализированные данные?

Почему несколько одноимённых секций, например:
section '.data' data readable writeable
не собирается в одну, а создаёт сегментную кашу?

Почему путь к include работает только через оболочечный fasmw и напрчь игнорируется в варианте с командной строкой через fasm.exe?, хотя и файлы fasm.ini, fasmw.ini содержат рекомендованную секцию с путём и в autoexec.bat путь в PATH прописан?

Почему W32dasm v 8.93 ругается, что файлы после FASM имеют не стандартный PE формат и не находит секции с данными?
Понятно, что прога не новая, но вроде бы и PE за последнее время не менялся?

 

А можно популярно - что це таке и с чем его вообще едят?

 

Y_Mur

Если в экзешнике присутствует секция data (инициализированных данных), а эта секция обычно присутствует, то bss вообще рекомендуется совмещать с data в одну секцию для экономии места. Тем не менее, в фасме вполне можно заменить "section '.bss' data readable writeable" на .bss или .data?, если так хочется:

Код (Text):

1. macro .bss { section '.bss' readable writeable }

Кстати говоря, в masm .data? - это тоже макрос.

Ассемблер обычно не должен отвечать за правильность кода - это обязанность программиста.

Обьявляешь кашу - получаешь кашу. Это только плюс, imho. Кстати, почему именно "каша", если последовательность соблюдается?

Оба фасма прекрасно поддерживают переменные окружения, через которые можно задать путь к include.

Сравните с описанием стандарта PE32. Любое расхождение сообщите автору фасма.

 

Quantum

а откуда такая инфа? в Microsoft Macro Assembler Reference я такого не нашел.

 

defaultplayer

.data? закрывает предыдущий сегмент, т.е. генерирует _TEXT ENDS (если перед .DATA? идёт .CODE) и создаёт новый:
_BSS SEGMENT

Примечательно, что использование этих макро-директив (.CODE, .DATA, .DATA? и .MODEL) всегда создаёт все 3 типа сегментов, даже если 1 или более из них имеют нулевой размер. Поэтому, для экономии места в обьектнике лучше создавать сегменты вручную, например:

Код (Text):

1. .486
2. _TEXT SEGMENT
3. ASSUME cs:_TEXT, ds:_BSS
4. ; Сюда кладём весь код
5. _TEXT ENDS
6.  
7. _BSS SEGMENT
8. ; Тут размещаем все данные
9. _BSS ENDS
10.  
11. end

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

 

ээ, пишу .data чего-то тут, дальше пишу .data? пишу там пара переменных, собираю, получился один сегмент .data, что я делаю не так?

зы: для того, чтобы бсс получить, я как-то с опциями компиляции/сборки баловался, но щас не вспомню, ибо очень редко надо

 

Интересная трактовка!!! А мне "почему то кажется" , что как раз .data? в .exe совсем не занимает места и выделяется после загрузки, а вот если совместить её с .data, то .exe будет набит совершенно не нужным мусором!!!
В FASM я аналога .data? так и не нашёл, больше всего похоже "section '.bss' data readable writeable", но если в ней случайно окажется хоть один инициализированный байт, то MASM (в .data?) выдаст предупреждение, а FASM молча (!) набъёт .exe мусором!!! из bbs

В MASM удобно размещать некоторые переменные около соответствующих им подпрограмм, а MASM сам позаботится о сборке их в один сегмент, а если действительно нужно много сегментов, ничего не мешает объявить их раздельно в нужной последовательности!!!, т.е. хвалёной свободы в данном случае больше в MASM.

 

Задаю в .ini [Environment]
include = C:/Fasm/INCLUDE/
, после этого fasmw нормально видит инклюды, fasm.exe нет, задаю в autoexec
set fasmincl = C:\Fasm\INCLUDE
после этого
include "%fasmincl%/win32a.inc"
посылает на... error
Что не так?

 

Y_Mur

Не занимает места содержимое секции, но у каждой секции есть ещё заголовок, в который помещается, к примеру, имя секции. Если совместить data и bss, причём bss разместить ПОСЛЕ data, то получается приличная экономия места.

 

Quantum
Так как всё таки в FASM сделать не инициализируемую секцию, не занимающую места в файле (сильно желательно, чтобы она случайно сама не превращалась в инициализированную)?

 

masquer

Всё равно линкер обьединяет все одноимённые сегменты в одну секцию, щедро разбавив выравниваниями на заданную по умолчанию границу. Поэтому нет особого смысла создавать несколько одинаковых сегментов в обьектнике, раз уж они потом всё равно попадут в одну секцию.

Достаточно дать сегменту другое имя и исключить из группы (второе актуально только для линкера ms), чтобы получить отдельную секцию, afair.

Y_Mur

fasm.exe не смотрит в ini.

autoexec ещё где-то используется??? На 2k/XP переменные окружения вносятся через панель управления. Кстати, если fasm.exe вызывается через батник, то SET fasmincl=C:\Fasm\INCLUDE можно добавить в него же (в батник).

Любая секция содержащая исключительно неинициализированные данные будет виртуальной.

Под случайностью я понимаю "ошибка программиста". Можно ли это исправить средствами макро или ещё как-то - не знаю, т.к. макросы принципиально не юзаю.

 

Y_Mur
Можно внутри секции написать что-то подобное:

Код (Text):

1. virtual at $
2.     bss = $
3.  
4. var SOMESTRUCT
5. var1    rd $100000
6. var2    dd 1,2,3,4,5
7.  
8.     size = $-bss
9. end virtual
10.     rb size

 

Black_mirror
Тогда он будет плакать, что инициализированные данные пропали.

Y_Mur

Головой думать надо просто, а не на предупреждения надеяться. Хотя если очень приспичит, можно написать макрос для .data?, который будет предупреждать, если кто-то попытается инициализировать переменную.

Код (Text):

1. section 's' data readable writeable
2. buf rb 10*1024*1024 ; 10 мб, кто не в курсе

И глянешь на размер файла.

Не угадал, это "link" заботится. Делай в фасме obj, собирай отдельным линкером — тогда сравнивай, что не так.

Quantum

То для удобства или когда "лениво"..

 

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

 

defaultplayer

Неинициализированная переменная - это переменная, которая не имеет фиксированного начального значения. То, что эти переменные всегда инициализируются нулями - побочный эффект. Неинициализированные переменные экономят место в экзешнике. К примеру, код, который чуть выше запостил IceStudent, задаёт массив размером 10Мб, но на размер экзешника это никак не влияет. Если бы массив был инициализированным, размер экзешника вырос бы на целых 10Мб сплошных нулей. К примеру, в C можно обьявить глобальную переменную так:
int a;

Или так:
int a = 1;

Скорее всего, в первом случае мы получим неинициализированную переменную, а во втором - инициализированную.

 

такой, маленький оффтоп.

на лекции по Системам Програмирования, у нас в универе, препод рассказал нам, что в процессоре всего 40 регистров. регистров еах - 8 штук.(и остальных тоже)(то есть обратиться можно только к одному, но на самом деле их 8)
то есть код:
mov eax,[p]
mov [y],eax
mov eax,[r]
mov ,eax
по скорости аналогичен:
mov eax,[p]
mov ecx,[r]
mov ,ecx
mov [y],eax

это правда про регистры? что их 40 по восемь на каждый?

ещё раз извините за оффтоп, но из за такой мелочи не хотелось создавать тему.

 

dead_body

Размер RRF зависит от модели процессора. В самом начале (до суперскаляра) регистры были не виртуальными, т.е. по одному на каждый, потом - по 2 штуки и т.д.

 

А как же распараллеливание инструкций? Оптимизация по Агнеру Фогу? Здесь же зависимости инструкций?

 

dead_body

И да и нет
Да - потому, что внутренних регистров действительно гораздо больше чем программных.
Нет - потому, что регистры RF не привязаны к программным регистрам, т.е. говорить "регистров eax - 8 штук" или "по восемь на каждый" - не правильно. Регистры RF привязаны к операциям (точнее к микрооперациям - мопам) - каждому мопу назначается новый регистр RF для записи результата. Поэтому и количество регистров зависит от того, сколько мопов могут одновременно находится в конвеере процессора - чем длиннее конвеер, тем больше должны быть RF и ROB (reorder buffer, в котором временно хранятся мопы). Поскольку современные процессоры суперскалярные и расчитаны на обработку в среднем до 3-х мопов за такт (Core 2 Duo до 4), то емкости RF и ROB должны быть не меньше утроенной задержки (в тактах) прохождения мопа по конвееру с выхода декодера (или T-кэша) до выхода в оставку (удаления из ROB). Например в PPro-PIII емкости RF и ROB = 40, а в P4E конвеер в 3 раза длиннее и соответственно емкости RF и ROB = 128.

IceStudent

Где ? True dependances одинаковые, а false dependances от "названий" регистров устраняются за счет их переименования