Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

OpenNews: Часто задаваемые вопросы по использованию ассемблера в Unix, opennews (?), 21-Ноя-05, (0) [смотреть все] аж в ностальгические чувства кинуло спасибо , SunTech (?), 22:34 , 21-Ноя-05, (1) вот такой бы хелп еще по рисковому ассемблеру, а также по переводу х86 на рисков, Гость (?), 02:24 , 22-Ноя-05, (2) // На wasm есть описание ARM ассемблера , mab (?), 11:10 , 22-Ноя-05, (8) // хотелось бы под PA-RISC , Аноним (-), 17:31 , 22-Ноя-05, (10) а там есть вопрос нафига нужен ассемблер в юниксе , злобный лоровский аноним (?), 07:43 , 22-Ноя-05, (3) // , Otto Katz Feldkurat (?), 10:56 , 22-Ноя-05, (5) // на выходе как раз ассемблер В который сунуть нос иногда не мешает , Otto Katz Feldkurat (?), 11:07 , 22-Ноя-05, (7) Хорошо 10nx , screepah (??), 10:19 , 22-Ноя-05, (4) Не поперло - провалился самый первый тестовый пример с выводом стороки Hello, w, Alexey (??), 10:59 , 22-Ноя-05, (6) // Первый пример предназначен для FreeBSD, в которой параметры системных вызовов пе, аноним (?), 03:30 , 23-Ноя-05, (11)   // нет, это в бзде пареметры через жопу передаються, а в линухе наиболее быстрым сп, _Nick_ (ok), 04:50 , 23-Ноя-05, (13)   // В FreeBSD обращение к системным вызовам происходит стандартным, для UNIX, способ, аноним (?), 07:18 , 23-Ноя-05, (14)   По слухам Линус просто читать Posix-стандарт поленился в свое время - , Andy (??), 09:05 , 23-Ноя-05, (15)   ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать , _Nick_ (ok), 06:25 , 24-Ноя-05, (20)   Студенты, они все такие Что-либо пытаются читать только за день-два до экзамена, Wulf (?), 11:49 , 24-Ноя-05, (24)   афтар, http voffka com archives affftarrr jpgЕсли ты решил, что POSIX - это пр, _Nick_ (ok), 22:58 , 24-Ноя-05, (27)   Вот Вам ссылка http www unix org version3 online html - вышлите ее Торвальдсу , Wulf (?), 01:57 , 25-Ноя-05, (29)   хорошо вам Оперируете современным положением А в средине 90-х сильно было поум, _Nick_ (ok), 00:22 , 26-Ноя-05, (30)   Лично мне кажется, что способ регистры и область в памяти эффективнее Даже ес, Dmitry U. Karpov (?), 00:55 , 24-Ноя-05, (19)   Возможно и верно в случае прямых вызовов подпрограм, обслуживающих syscall В ре, Wulf (?), 11:31 , 24-Ноя-05, (23)   У Вас небольшая опечатка, правильно usr src sys i386 i386 trap cКстати, есть ли, аноним (?), 17:56 , 24-Ноя-05, (25)   Я не особо авторитетный человек в этом вопросе, но насколько знаю, для софтверны, Wulf (?), 21:16 , 24-Ноя-05, (26)   Под FBSD6 0 проверил все работает , ws (ok), 12:41 , 22-Ноя-05, (9) Теперь надо написать пример простого файлового вируса на ассемблере, который зар, аноним (?), 03:47 , 23-Ноя-05, (12) Неплохой ресурс по теме, правда BSD-центричныйhttp www int80h org bsdasm , Wulf (?), 17:23 , 23-Ноя-05, (17) а есть вирусы работающие в линукс или бзде , 4 (?), 09:33 , 24-Ноя-05, (22) // есть, аноним (?), 01:33 , 25-Ноя-05, (28) небольшая поправка к статье в ответе как слинковать, запустить в 4-ом вари, Mranton (??), 02:00 , 30-Ноя-05, (31) 1,2,3,4,6,9,12,17,22,31

Сообщения

[Сортировка по времени | RSS]

	11. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от аноним (?), 23-Ноя-05, 03:30
	Первый пример предназначен для FreeBSD, в которой параметры системных вызовов передаются нормальным образом - через стек. В Linux эти параметры передаются через жопу - если их мало, то через регистры, а если много, то через структуру в памяти. Используй код, предназначенный для Linux.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от _Nick_ (ok), 23-Ноя-05, 04:50
	>Первый пример предназначен для FreeBSD, в которой параметры системных вызовов передаются нормальным >образом - через стек. В Linux эти параметры передаются через жопу >- если их мало, то через регистры, а если много, то >через структуру в памяти. Используй код, предназначенный для Linux. нет, это в бзде пареметры через жопу передаються, а в линухе наиболее быстрым способом в каждом случае ищеться оптимальный метод. Докажи обратное.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от аноним (?), 23-Ноя-05, 07:18
	В FreeBSD обращение к системным вызовам происходит стандартным, для UNIX, способом, что упрощает переносимость. В Linux используются сразу два нестандартных способа - через регистры и, если их не хватает, через структуру в памяти. В первом случае ядру всё равно приходится куда-то переписывать параметры внутри системных вызовов. Ведь регистры, которых не много, нужны для работы, а не для хранения параметров. Во втором случае нужно выделять память под структуру параметров, записывать в ebp её адрес и в конце освобождать эту память. Использование стека упрощает и автоматизирует всё это. Вообще, использование ebp для передачи более пяти параметров появилось только в 2.4.x, как костыль. Если бы я не знал, что Linux создавался человеком, до этого использовавшим  Minix, я бы решил, что всё, что он до этого видел, была лишь DOS, в которой именно так всё и работает.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Andy (??), 23-Ноя-05, 09:05
	По слухам  Линус просто читать  Posix-стандарт поленился в свое время :-)
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от _Nick_ (ok), 24-Ноя-05, 06:25
	>По слухам  Линус просто читать  Posix-стандарт поленился в свое время >:-) ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %)))) ЛОЛ
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Wulf (?), 24-Ноя-05, 11:49
	> ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %)))) Студенты, они все такие. Что-либо пытаются читать только за день-два до экзамена. Даже, если имеют конспекты всех лекций.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от _Nick_ (ok), 24-Ноя-05, 22:58
	>> ага, искал посикс стандарты по всему миру как угорелый, но ленилсо их читать %)))) >Студенты, они все такие. Что-либо пытаются читать только за день-два до экзамена. >Даже, если имеют конспекты всех лекций. афтар, http://voffka.com/archives/affftarrr.jpg Если ты решил, что POSIX - это просто дока, которую мона скачать и начитаццо досыта - ты ошибаешься. Набор этих стандартов ДЕНЕГ СТОЯТ. И НЕМАЛЫХ ДЕНЕГ. Торвальдсу их высылали по кускам, кто что имел. И поверь он их не фтопку складывал. Все отсупления от посикса у Торвальдса аргументированы. Как например посикс определяет процесс как набор нитей. А в линухе есть группы процессов (соотвествует POSIX процессу) и процессы (они же нити). Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Wulf (?), 25-Ноя-05, 01:57
	> Если ты решил, что POSIX - это просто дока, которую мона скачать и начитаццо досыта - ты ошибаешься. Набор этих стандартов ДЕНЕГ СТОЯТ. И НЕМАЛЫХ ДЕНЕГ. > Торвальдсу их высылали по кускам, кто что имел. Вот Вам ссылка http://www.unix.org/version3/online.html - вышлите ее Торвальдсу и Ваше имя попадет в историю линукса. > Все отсупления от посикса у Торвальдса аргументированы. > Как например посикс определяет процесс как набор нитей. А в линухе есть группы процессов (соотвествует POSIX процессу) и процессы (они же нити). Не путайте теплое с мягким: posix определяет интерфейс для т.н. user threads (пользовательских нитей), то, что Вы называете группами процессов и процессами линуха, на самом деле является kernel threads (тьфу-ты, procs) и POSIX-ом не регламентируется. Тип связи между ними выражается цифирками 1:1, N:M и т.д. и закладываетя в libpthreads. Времени нет объяснять Вам дальше, что это такое, поройтесь в Google. > Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге. В проектировании NPTL упор делался на light weight в ущерб fairness-у шедулинга. По сравнению с, например, NGPT (не буду сравнивать с BSD и соляркой), времена исполнения группы "одинаковых"(если так можно выразится) тредов будет иметь несколько меньшее мат. ожидание при большей дисперсии. Так, что для задач, у которых критично именно максимальное, а не среднее время отклика, NPTL учитывает все не самым полноценным образом.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от _Nick_ (ok), 26-Ноя-05, 00:22
	>Вот Вам ссылка http://www.unix.org/version3/online.html - вышлите ее Торвальдсу и Ваше имя попадет >в историю линукса. хорошо вам. Оперируете современным положением. А в средине 90-х сильно было поумничать негде...  ну и почитать нахаляву. (кста, остальные 8 частей где мона нарыть ? - возможно путаю общее количество разделов посикса, ну а если это все - то все ок, современные торвальсды имеют больше возможностей проявить себя) >Не путайте теплое с мягким: posix определяет интерфейс для т.н. user threads >(пользовательских нитей), то, что Вы называете группами процессов и процессами линуха, >на самом деле является kernel threads (тьфу-ты, procs) и POSIX-ом не >регламентируется. Тип связи между ними выражается цифирками 1:1, N:M и т.д. >и закладываетя в libpthreads. Времени нет объяснять Вам дальше, что это >такое, поройтесь в Google. писал это по памяти с цытаты Торвальдса. Но суть передал четко. Хотя, я сам посикс по вопросу не читал. >> Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге. >В проектировании NPTL упор делался на light weight в ущерб fairness-у шедулинга. возможно. Не знаю о чем именно и когда говорил Торвальдс. Возможно с тех пор многое изменилось. >По сравнению с, например, NGPT (не буду сравнивать с BSD и >соляркой), времена исполнения группы "одинаковых"(если так можно выразится) тредов будет иметь >несколько меньшее мат. ожидание при большей дисперсии. да, смотрю ты это курил в правильном математическом свете. Я пока недотягиваю (не интересовало именно это пока что) >Так, что для задач, >у которых критично именно максимальное, а не среднее время отклика, NPTL >учитывает все не самым полноценным образом. возможно. Не стремился это проверить.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Dmitry U. Karpov (?), 24-Ноя-05, 00:55
	Лично мне кажется, что способ "регистры и область в памяти" эффективнее. Даже если ядро переписывает данные из регистров куда-то ещё, код для переписывания существует в системе только один раз, а не встречается в каждой программе. Да, регистры действительно нужны для работы. Но так ведь передаваемые параметры тут же включаются в работу! Кстати, на RISC-процессорах с их большим числом регистров это очень выгодно. Кстати, хочу напомнить, что DOS создавался для работы в очень стеснённых условиях: сначала памяти просто было мало, а потом адресное пространство было ограничено бинароной совместимостью с программами, написанными для реального режима i80*86. Так что ругать какой-то метод только за то, что он использовался в DOS - это всё равно, что ругать военно-тактические приёмы за то, что когда-то они использовались гитлеровцами. Передача параметров через регистры и область в памяти происходила не только в DOS, но и во многих др.операционках того времени.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	23. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Wulf (?), 24-Ноя-05, 11:31
	> способ "регистры и область в памяти" эффективнее. Возможно и верно в случае прямых вызовов подпрограм, обслуживающих syscall. В реальности вызывается сначала обработчик int80h. - для BSD /usr/src/i386/i386/trap.c, в котором происходят проверки на MP_SAFE и глобальных блокировок, вызовы процедур трассировки syscall-ов, различный отладочный код и еще куча всего. И только после всего этого происходит передача управления самому syscall-у. Регистры так или иначе придется сохранять и восстанавливать. Со стеком тут все проще - для передачи параметров достаточно 1-го вызова copyin (копирования области памяти из user-space в kernel) > Так что ругать какой-то метод только за то, что он использовался в DOS Что использовалось в DOS и других "наколенных" ОС того времени трудно вообще назвать методами. Методами это стало уже в линуксе.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от аноним (?), 24-Ноя-05, 17:56
	> для BSD /usr/src/i386/i386/trap.c У Вас небольшая опечатка, правильно /usr/src/sys/i386/i386/trap.c Кстати, есть ли какие-то существенные отличия между вызовами int $0x80 и lcall $7,$0 кроме того, что после lcall $7,$0 нужно делать addl $16,%esp ?
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Часто задаваемые вопросы по использованию ассемблера в Unix"	+/–
	Сообщение от Wulf (?), 24-Ноя-05, 21:16
	> есть ли какие-то существенные отличия между вызовами int $0x80 и lcall $7,$0 Я не особо авторитетный человек в этом вопросе, но насколько знаю, для софтверных прерываний разницы, кроме скорости исполнения конкретно этих 2-х инструкций, нет. Краем уха где-то слышал, что в SCO применяется именно lcall. >  кроме того, что после lcall $7,$0 нужно делать addl $16,%esp addl нужно делать не для lcall, а для восстановления указателя стека после возврата из подпрограммы при cdecl стиле передачи параметров. Он компенсирует изменение esp от серии push
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема