LINUX.ORG.RU

Нужны идеи как реализовать аналог досовских софтверных прерываний в линуксовом юзерспейсе

 , software interrupts,


1

2

Интересует все, даже самые безумные идеи.

«Обработчики» тоже должны быть в этом самом процессе.

Предпочтительно без использования инструкции call.

Переключение в ядро недопустимо.

UPD: В некотором смыле мне нужна наиболее короткая инструкция способная сделать call по таблице. Досовские софтверные прерывания занимали кажется всего один или два байта и именно поэтому ихняя идея взята за образец.

UPD2: Если вы думаете что это нечто странное то я с вами полностью согласен :-)

★★★★★

Последнее исправление: cvv (всего исправлений: 4)

setjmp/longjmp

anonymous
()
Ответ на: комментарий от Harald

насколько я помню в 32-х битном режиме это вызовет переключение в ядро, а если это скомпилится в 64-х битном режиме то я буду вообще удивлен.

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 1)

Эмуляция (dosbox, ага) или претрансляция.

tailgunner ★★★★★
()

то, что ты хочешь, архитектура x86 не умеет

Harald ★★★★★
()

Не очень понятно что именно тебе нужно. Чем не угодили просто вызовы обычных функций?

Deleted
()

raise (SIGUSR1);

Переключение в ядро недопустимо.

Да иди ты

anonymous
()

Интересует все, даже самые безумные идеи.
«Обработчики» тоже должны быть в этом самом процессе.
Предпочтительно без использования инструкции call.
Переключение в ядро недопустимо.

inline void like_a_dos_soft_int() { do_it(); }

Какой-то смысл в именно прерываниях появится когда они будут не только софт но и асинхронные, разве нет?

amaora ★★
()

Я бы спросил автора: зачем это тебе? Может и решение другое подскажется.

I-Love-Microsoft ★★★★★
()

man идеи rust-а

anonymous
()

Софтверные прерывания тебе не нужны.

Весь смысл прерываний как раз в том, что они изначально хардверные, т.е. инициируются железом, а не софтом. То, что этот механизм иногда используют и «софтово», вовсе не означает, что это способ решения твоей задачи. Тем более, если тебе заведомо нужно оставаться в юзерспейсе.

Просто пользуй обычную глобальную функцию и будет тебе счастье.

Если очень хочется странного и возможности дёргать твоё «прерывание» снаружи - можешь signal, например, использовать.

Stanson ★★★★★
()

Предпочтительно без использования инструкции call

а что в ней такого ?? можно заменить на jmp (что компилеры и делают). «int» требует поддержки ядра (уж так всё несправедливо устроено).

а вам кстате для каких целей ? если чисто учебные (иначе не представляю зачем такой изврат) - реализуйте green-threads и первые 255 записей в таблице «задач» обрабатывайте особым образом

MKuznetsov ★★★★★
()
Ответ на: комментарий от slovazap

впринцыпе, наверное да. разница в длине инструкции. В некотором смыле мне нужна наиболее короткая инструкция способная сделать call по таблице.

cvv ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

Развлекается с диковинными кибер-гусями.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

Автор конечно нарк, но возможно он делает что-то типа интерпретатора байткода и ему нужна короткая инструкция чтобы удобно было везде ее вставлять. хотя причем тут DOS я так и не понял.

pftBest ★★★★
()

без использования инструкции call

Гм.

Если нужно перейти по адресу в таблице, в gcc есть поддержка indirect goto: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Это просто переход, как возвращаться нужно придумывать самому. Или придумывать как не возвращаться.

Такие штуки используют для шитого кода (threaded code) в фортовских (а может быть еще каких-нибудь) виртуальных машинах. Вот, например, как-то так: https://www.complang.tuwien.ac.at/forth/threaded-code.html

нужна наиболее короткая инструкция способная сделать call

На x86 вроде есть indirect call, можно дать инструкции адрес памяти где лежит адрес функции. Должно быть очень компактно, буквально одной инструкцией.

Но это получится непонятная (и платформозависимая) экономия. Лучше в массив забить указатели на функции, а дальше пусть компилятор думает как их вызывать

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.