ассемблер под FreeBSD

стоит ли программировать на асме

В общем случае нет. Зачем?

под FreeBSD

ОС почти не имеет значения.

можно ли напрямую обратиться к портам того или иного устройства, запретить или разрешить прерывания?

Можно, если пишешь модуль ядра, только для всего этого и много другого есть удобные функции/макросы на C.

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

Минусы ассемблера - отсутствие переносимости, трудоемкость кодирования/отладки на порядок выше. Плюсы - хорошее понимание «как все работает».

> хотя ассемблер все равно стоит знать.

Плюсы - хорошее понимание «как все работает».

Все-таки лучшей платформой для этих целей будет Windows. Больше литературы, примеров, форумов.

http://www.linux.org.ru/news/opensource/4760221

вот специально как для вас заказ )

стоит ли программировать на асме под <на самом деле любую ОС>

нет, пишите на Си, он портируемый, большинство драйверов как в линукс так и в ядре FreeBSD на нем и написано и обращаться к устройствам это не мешает

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

еще один вопрос: возможно ли писать на си и использовать ассемблерные вставки в линуксе?

да

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

вы сможете написать одну и туже программу на асме под все процессорные архитектуры?

«Ассемблер не нужен!»(с) Но если очень хочется - то можно. «Но зачем?» (с) Как-то так...

Скажу вам честно: не заморачивайтесь с асмом, лучше потратьте время на что-то более полезное. Говорю так из-за того, что сам прошёл этот путь, около 3 лет юзал асм для всего где он нужен и где нет.
Единственный плюс: появляется понимание как работает железо (а главное проц), что даёт возможность вырвать пару тактов при написании реальных программ (знаешь, скажем, что x>>1 быстрее, чем x/2), но только это нафиг никому не далось. Зато появляется стойкая тяга к преждевременной оптимизации и вот только хотя бы из-за этого я бы крайне не рекомендовал брать асм в качестве одного из первых ЯП.
Единственное, где он нужен, так это или что-то, связанное с SIMD, или при разработке компиляторов, ну или при написании вируса. Пожалуй, всё.

Более того, вся эта оптимизация — это всего лишь отголосок того как может работать данная программа. Любой gcc закодирует намного лучше (я даже не принимаю во внимание размер программы).
Ну да, зная асм, я могу на глаз оценить размер инструкций в байтах, сколько тактов они будут исполняться (с учётом U- и V-конвееров), но банально оптимально использовать все регистры (для большой подпрограммы), учитывать заполнение кеш-линий, переименования регистров, анализировать положение блоков ветвления условий, да учитывать всю прочую фигню (которая у разных процессоров разная, между прочим) это я уже не осилю, тут во все поля математические методы, графы, да прочие эвристики, это уже обычному человеку просто не под силу.
Вот и имеем: вместо того чтоб алгоритм продумывать, первым делом бросаешься регистры распределять, да блоки кода местами менять, а за это время другой сообразит алгоритм получше (да и gcc на выходе даст код получше нашего). Так, что ну его нафиг, уж лучше функциональщину учить, от неё хоть какой толк есть.

>вы сможете написать одну и туже программу на асме под все процессорные архитектуры?

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

Поботай NASM.

Скажу вам честно: не заморачивайтесь с асмом, лучше потратьте время на что-то более полезное.

Эн нет, развитие кругозора еще никому не вредило.

Единственное, где он нужен, так это или что-то, связанное с SIMD, или при разработке компиляторов, ну или при написании вируса. Пожалуй, все.

Эн нет... ASM x86 - это не весь асм.
Встроенные системы гарвардской архитектуры с очень малым объемом секции кода. Например, самые дешевые AVR, 8051, PIC с 512 байт кода на борту.
Там надо влезть в кристалл, а на C это сложнее сделать.
А суть в том, что это будет контроллер какого-то очень простого процесса. Такие МК стоят дешевле, чем носки на базаре.
А код назмером в 512 байт вполне читабелен на асме.

Используй виртуальную машину.
От асма под freebsd еще меньше профита, чем под вин.

к регистрам устройств и.т.д, можно прекрасно обращаться без всего этого.

>> можно ли напрямую обратиться к портам того или иного устройства,

запретить или разрешить прерывания?

Можно, если пишешь модуль ядра, только для всего этого и много другого

есть удобные функции/макросы на C.

Не только. См. man 2 inb

ну это уже совсем очевидно=)

Кстати, получается, что и прерывания можно запретить, записав в некий порт.
Конечно, это не общий случай.

Встроенные системы гарвардской архитектуры с очень малым объемом секции кода. Например, самые дешевые AVR, 8051, PIC с 512 байт кода на борту.
Там надо влезть в кристалл, а на C это сложнее сделать.

Пусть попрограммирует на калькуляторе «Электроника MK-61"или на его современной инкарнации — ЭЛЕКТРОНИКА МК-161.

Минусы в том, что под UNIX используется в основном GAS и NASM. В первом AT&T синтаксис, который слегка необычный для x86 программистов, и еще мало встроенных макросредств. Во втором все же Intel синтаксис, но макросредств все так же мало. Конечно все относительно и не факт что они нужны, но если вы работали раньше в Windows, то после MASM будет немного... низкоуровнево и примитивно) В случае с GAS это не удивительно. Он не позиционировался разработчиками как ассемблер для пользования человеком. Где-то я это читал...

Я не могу сказать о FreeBSD, но в Linux зато есть другие плюсы по сравнению в Windows. Разработка драйверов намного проще и понятнее. Никаких жутких тридцатибуквенных идентификаторов. Никаких стремных DDK - просто исходник ядра. Взаимодействие с пользователем максимально удобно. И есть книжка от Novell - Linux Kernel Development. Они там рассказывают как устроено ядро.

Нужно заметить что в Linux не принято писать на ассемблере. И драйвер, который мы писали в Ubuntu 8.10 пришлось переписывать почти заново для новой версии ядра, которое оказалось в следующей Ubuntu 9.04 (я уже не помню точные версии ядра). То что было функцией - стало макросом, который вызывает другую функцию. Казалось бы, в С - делов то, а тут пришлось кромсать код.

По разработке модулей на асме ровно 0 документации в интернете. Документация получается путем программирования на С по реальной документации, а потом компиляцией исходников на gcc с опцией -S. Тогда генерируется компилируемый листинг на асме, который можно ковырять, изучать.

Итог:

- разработка модулей под Linux - прекрасна

- на ассемблере - ужасна, нужна в учебных целях

> Можно, если пишешь модуль ядра, только для всего этого и много другого есть удобные функции/макросы на C.

Да. Разработчики ядра сделали ВСЕ что могли, чтобы ВСЕ можно было написать на С без ассемблера в принципе. Но все же код на асме встречается в ядре, но не так уж и много.

> Встроенные системы гарвардской архитектуры с очень малым объемом секции кода. Например, самые дешевые AVR, 8051, PIC с 512 байт кода на борту.

Ну с этим не могу не согласиться, тут целое направление (весьма перспективное, кстати). И если человек хочет туда пойти, то бесспорно флаг ему в руки. Но, на мой взгляд, для рядового computer engineer`а большие дозы асма ведут прогрессированию синдрома преждевременной оптимизации, что не есть хорошо.

Кстати, gas давно поддерживает синтаксис Intel. Только переучиваться там - 5 минут.

И еще ТСу:

FreeBSD Developers' Handbook

Assembly language programming under UNIX® is highly undocumented. It is generally assumed that no one would ever want to use it

Linux Assembly HOWTO

Finally, if you still want to try this crazy idea and write something in assembly (if you've reached this section — you're real assembly fan)...

> FreeBSD

вот снобы

Linux

браво! ))

Я знаю о той опции. Лучше выучить AT&T, привыкнешь, проблем не будет, зато gcc -S генерирует код в нем

fasm

> Ну с этим не могу не согласиться, тут целое направление (весьма перспективное, кстати). И если человек хочет туда пойти, то бесспорно флаг ему в руки. Но, на мой взгляд, для рядового computer engineer`а большие дозы асма ведут прогрессированию синдрома преждевременной оптимизации, что не есть хорошо.

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

Преждевременная оптимизация - это когда программа работает быстро, занимает мало, ничего не умеет и обладает нечитабельным кодом. И еще когда вместо «x = 0» пишут «x ^= x» в функции сортировки методом пузырька.

В свое время тоже заморачивался ассемблером, только под linux. помог вот этот ресурс: linuxassembly.org Он до сих пор живой ))