Перейти к содержанию
    

Можно ли так делать в Си или это моветон?

В ассемблере так часто делал. Стек разгружал. А в Си так можно?

 

Если нужно конкретно платформа - Keil5, контроллер STM32.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Формально - нет. Да и неправильно это, как компилятор отследит разный calling convention, да еще и с varargs

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для этого есть функции setjmp и longjmp, но запутать таким образом программу и заложить трудновыявляемые глюки элементарно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В ассемблере так часто делал. Стек разгружал

 

ой, "два CALL и один RET" или даже "два CALL и один JMP" стек не то что разгрузят, но "испортят" хоть в C хоть в ASM (не вернут в прежнее состояние, будет некий StackLeak который при таких N-вызовах порушит всё )

вы уверены в своих ранее написанных программах ? Или может я что-то не понимаю

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, это моветон.

Такое применяется только там где уже нечего беречь - выбрасывание исключений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ой, "два CALL и один RET" или даже "два CALL и один JMP" стек не то что разгрузят, но "испортят" хоть в C хоть в ASM (не вернут в прежнее состояние, будет некий StackLeak который при таких N-вызовах порушит всё )

вы уверены в своих ранее написанных программах ? Или может я что-то не понимаю

pop sp, Dec sp и jmp. Да, 15 лет до сих пор пашет.

 

Да, это моветон.

Такое применяется только там где уже нечего беречь - выбрасывание исключений.

Попробовал setjmp и longjmp. Работает. Но раз моветон, применять не буду. Самому не понравилось такое решение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

pop sp, Dec sp и jmp. Да, 15 лет до сих пор пашет.

И вы гарантируете одинаковость имплементации такой конструкции на всех процессорах? Что первично, inc/dec или mov?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробовал setjmp и longjmp. Работает. Но раз моветон, применять не буду. Самому не понравилось такое решение.

Эти функции использовались в С до появления в С++ исключений. Применять их стоит только в реально крайних случаях, когда нужно вернуться в указанную точку. Введение кучи флагов и их анализа для выполнения того же самого вряд ли сделает программу лучше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И вы гарантируете одинаковость имплементации такой конструкции на всех процессорах? Что первично, inc/dec или mov?

Конечно нет. Я для 8051 писал. Мне на "все" и не надо было.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

. . .

Попробовал setjmp и longjmp. Работает. Но раз моветон, применять не буду. Самому не понравилось такое решение.

Если "нельзя", моветон, но "оченьнадо". Оченьнадо - это авария по питанию.

Есть в моем проете один longjmp. Обеспечивает "выпрыгивание" из вектора прерывания в блок,

находящийся в начале main().

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Эти функции использовались в С до появления в С++ исключений. Применять их стоит только в реально крайних случаях, когда нужно вернуться в указанную точку. Введение кучи флагов и их анализа для выполнения того же самого вряд ли сделает программу лучше.

Да ладно. "Моветон" и т.п. - что за пуританство? Если это улучшает читаемость кода и стройность алгоритма, то применять можно и нужно.

Сам так иногда делаю. Когда нужно вернуться в предопределённое положение (функцию) из дерева вложенных вызовов из множества мест. Реализовывать такое на специальных возвращаемых значениях (в каждой функции, из которой может быть такой возврат!) - это будет куча лишнего кода.

Куда элегантнее и прозрачнее будет восстановить стековый фрейм.

А насчёт "на всех процессорах": а это реально так нужно? А ничего если в используемой ОС тоже есть ассемблерные вставки и перенос её на другое ядро производится написанием порта под нужное ядро? Кто же мешает так сделать и в этом случае? Тем более что кода тут - с гулькин нос.

 

В конце концов: си (или ++) - это инструмент, а не самоцель. А цель всё-таки - это наиболее эффективное решение задачи (написание эффективного ПО).

 

PS: си-шными setjmp/longjmp я не пользуюсь. Пишу свои асм-функции сохранялки/переключалки стекового фрейма.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это даже у системных программеров под Винду (конкретно мы, группа, реализовывали свой драйвер COM порта, ...15 лет назад) было моветоном.

Можно писать как угодно коряво, но лучше красиво. В грамотных ассемблерных вставочках комментарий в каждой строке. Код должен своим видом показывать, что он правилен. Как-то так ИМХО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...