fasm синтаксис

Привет всем!

Решил немного разгрузить мозги чем-то другим, отличным от рабочих вопросов. И вот мой выбор пал на тему "ассемблер" В свое время плотно прогал на Turbo Pascal 5.5 + TASM, но это было ооочень давно. В основном это касалось работы с видеоадаптером CGA. А когда появились EGA/VGA - актуальность начала падать. Ну это так, предисловие что-ли. Сейчас решил немного окунуться "в современнсть". Ассемблеров тьма, мне приглянулся fasm. Написал простенькую прогу для теста:

format PE64 console
 
include "C:/Tools/Fasm/INCLUDE/win64ax.inc"
 
.data
 
Message         db 'Hello World!',0
Message.length  = $ - Message
HandleFile      dq ?
 
.code
 
proc PrintFunc
  stdcall [WriteConsole], [HandleFile], Message, Message.length, 0, 0  
  ret
endp
 
start:
 
  sub rsp, 40  ; резервирование в стеке (4 * 8) + 8
  and spl, -16 ; и выравнивание на 16
 
  stdcall [GetStdHandle], STD_OUTPUT_HANDLE
  mov [HandleFile],rax
  stdcall PrintFunc, HandleFile
  stdcall [ExitProcess],0
 
.end start

Где-то по докам, где-то по примерам из сети. Но обратил внимание на странное оформление секций, процедур. Вот и возник ряд вопросов:

1) Это фишки собственных макросов fasm'а?
2) А как такое же написать, к примеру, для nasm?
3) А такое же, написанное для п.2 потом сам fasm компильнет?
4) Какова ценность вот такого "синтаксиса" (вдруг потом понадобится gas'ом компилячить)?

Сорри, если вопросы совсем наивные

Цитата JoeUser @ 31.03.20, 04:53

И вот мой выбор пал на тему "ассемблер"

И это абсолютно верный выбор, особенно в условиях кризиса

Цитата JoeUser @ 31.03.20, 04:53

Ассемблеров тьма, мне приглянулся fasm.

Ты не перестаёшь меня удивлять правильностью своих решений!

Цитата JoeUser @ 31.03.20, 04:53

1) Это фишки собственных макросов fasm'а?

Да, это фишки макросов из папки include.

Цитата JoeUser @ 31.03.20, 04:53

2) А как такое же написать, к примеру, для nasm?

Помимо компьютера (работающего) нужно всего 3 вещи: голова, пальцы и клавиатура. А, ну и желательно, чтобы электричество было, лучше бесперебойное.
Вообще, есть уже подобное, называется NASMX. Сходи-ка ты в Полезные ссылки, поищи там это хитрое забугорное слово и кликни на ссылку под ним.

Цитата JoeUser @ 31.03.20, 04:53

4) Какова ценность вот такого "синтаксиса" (вдруг потом понадобится gas'ом компилячить)?

"Такого" – это какого?
У каждого асма свои прибабахи. У MASM – одни, у NASM – другие, у fasm – третьи. Да и у GAS их хватает, чего стоит только AT&T-синтаксис.
Придётся переводить тогда, куда ж деваться?! Тут нет единого стандарта в отношении отдельных нюансов синтаксиса и уж тем паче директив и макросов, как у плюсов.
Ещё хуже, если ты напишешь код под 64 бита под Windows, а тебе потом нужно будет переводить его в 32-битный, да ещё и под Linux. А ещё лучше (вернее, хуже) – под ARM какой-нибудь.
Вот захочу я свой асм создать (вернее, я уже хочу... начну, хотел сказать), а там такое будет! Тогда вообще непонятно станет, как дальше жать.

Цитата Jin X @ 31.03.20, 17:56

Помимо компьютера (работающего) нужно всего 3 вещи: голова, пальцы и клавиатура. А, ну и желательно, чтобы электричество было, лучше бесперебойное.
Вообще, есть уже подобное, называется NASMX. Сходи-ка ты в Полезные ссылки, поищи там это хитрое забугорное слово и кликни на ссылку под ним.

А если не использовать макросы вообще? Можно будет один и тот же код копилять и fasm, и nasm, и gas (c intel флагом)?

Макросы можно не использовать.
Можно даже директивы не использовать, но в довольно ограниченных случаях.
Часто возникает необходимость указывать секции (code, data, bss), а тут уже есть различия.

Еще немножко вопросов ...

Переписал свой первый пример с другим форматом оформления секций:

format PE64 console
entry start
 
include "C:/Tools/Fasm/INCLUDE/win64ax.inc"
 
section '.data' data readable writeable
 
  Message         db 'Hello World!',0
  Message.length  = $ - Message
  HandleFile      dq ?
 
section '.text' code readable executable
 
start:
 
  sub rsp, 40  ; резервирование в стеке (4 * 8) + 8
  and spl, -16 ; и выравнивание на 16
 
  invoke GetStdHandle, STD_OUTPUT_HANDLE
  mov [HandleFile],rax
  stdcall PrintFunc, HandleFile
  invoke ExitProcess,0
 
proc PrintFunc
  invoke WriteConsole, [HandleFile], Message, Message.length, 0, 0  
  ret
endp
 
section '.idata' import data readable writeable
 
  library kernel32,'KERNEL32.DLL'
  include 'api\kernel32.inc'

Вопросы:

1. При таком оформлении без явного указания секции .idata компилируется с ошибкой. А почему в первом примере этой секции не требовалось?
2. Имеет ли смысл секцию .data объявлять как 'readable' и добавлять секцию .bss как 'readable writeable'
3. Кстати не совсем понятно назначение .bss, в чем особенность, отличие от .data?

Цитата JoeUser @ 02.04.20, 01:50

При таком оформлении без явного указания секции .idata компилируется с ошибкой. А почему в первом примере этой секции не требовалось?

Потому что в первом примерё она задаётся в макросе .end.

Цитата JoeUser @ 02.04.20, 01:50

Имеет ли смысл секцию .data объявлять как 'readable' и добавлять секцию .bss как 'readable writeable'
Кстати не совсем понятно назначение .bss, в чем особенность, отличие от .data?

Секция '.data' вполне может быть и writeable.
Разница их в том, что в '.data' обычно хранятся инициализированные данные, а '.bss' – нет (это секция неинициализированных данных, хотя фактически данные, заданные в конце секции через rb, rw, rd, rq, обнуляются системой при загрузке кода, как и в '.data'). По большому счёту, на практике разницы нет, можно писать rb в '.data' и db в '.bss'. Т.е. fasm просто даёт им разные имена, вот и вся разница

Jin X, понятненько ... я не прощаюсь!

Jin X, хелп!
Нужен исходник и коммандная строка fasm чтобы в результате получить бинарный файл,
размером 32 байта, заполненный нулями, а последний байт пусть будет F4.

UPD: Отбой, сам разобрался ...

stuff db 31 dup(0)
hlt

fasm test.asm test.bin