Easyelectronics.ru

Электроника для всех
Текущее время: 24 июн 2018, 04:30

Часовой пояс: UTC + 5 часов


Правила форума


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


    • JLCPCB - Платы прототипов всего за 2$ c бесплатной доставкой (при первом заказе)
    • 10 PCBs за $2 для 2 слоев, $15 для 4 слойной, $74 для 6 слойной платы.
    • Крупнейший китайский производитель прототипных плат. 290000+ клиентов & 8000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин радиодеталей.

Начать новую тему Ответить на тему  [ Сообщений: 352 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15  След.
Автор Сообщение
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 26 июн 2017, 01:24 
Старожил
Аватара пользователя

Зарегистрирован: 26 янв 2010, 21:48
Сообщения: 3718
Откуда: Звенигород
После упоминания макроассемблера некоторым нужно было еще вспомнить про фигню для авр, которая с квадратиками и стрелочками, забыл ее название))) Там еще у ее сторонников переменные назывались исключительно в стиле DenNedeli, а функции UvelichitDatu. И убедительно доказать, что без нее армы вообще нежизнеспособны, а с ней наступил бы программисткий рай)))

_________________
От Парижа до Находки с водкой лучше, чем без водки!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 26 июн 2017, 15:13 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 11:56
Сообщения: 2686
Откуда: Винница
Да ладно... Global_Wayt, или SkanServChen, или Adr_Taim0 - сильно лучше? ;)
Show

Да, там ассемблер был... с некоторой натяжкой даже макро.

_________________
Китайская комплектация - европейское качество!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 06 июл 2017, 01:11 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 393
aamonster писал(а):
Это не макроассемблер прост, это вы ограничиваетесь относительно простыми задачами :-)

Да я не ограничиваюсь, какие задачи возникают, такие и решаю. Пока максимальный объём был 32 кБ, в следующем проекте понадобится, наверно, 64 кБ.
Макроассемблер, правда, увеличивает объём, но не много, процентов десять, двадцать.
В одном проекте приходилось одновременно работать и с ATMega8, и с ATMega32. Как-то нет особой разницы. В любом случае непосредственно работа идёт с небольшим участком кода, а где этот участок расположен, в большой программе или малой, особого значения не имеет. Правда, большой МК дольше программируется, при отладке неудобство.

aamonster писал(а):
Абсолютная характеристика: количество различных конструкций в языке (для асма - как минимум список мнемоник, регистров и режимов адресации)
Более реальная характеристика: передайте проект другому разработчику и посмотрите, за какое время он "въедет".

Про абсолютную характеристику не понял, что там плюс, что минус.
Передавал коллеге часть кода (следящая схема), вроде не было проблем.
У меня последний проект на ATMega16, думаю, в основу проекта вы «въедете» минут за двадцать.
aamonster писал(а):
А насчёт проблемы отладки на асме - нет никакой проблемы, просто знания и навык/опыт. (Причём знания включают в себя не только сам асм, но и calling conventions компиляторов).

Для меня основным инструментом при отладке является дебаггер. Когда при отладке в реальном режиме времени можно, практически, в любом месте просмотреть любую переменную, всё резко упрощается.
Про calling conventions даже не слышал, посмотрел по интернету. Наверно, при вызове функции у себя действую по-другому. При вызове функции регистры РОН (это AVR), используемые в этой функции, забрасываю в стек, по завершении функции возвращаю. А аргументы передаю через SRAM.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 06 июл 2017, 01:28 
Старожил

Зарегистрирован: 19 мар 2013, 19:37
Сообщения: 2447
Откуда: Санкт-Петербург
Calling conventions - это в основном для языков высокого уровня. Как передаются аргументы и результаты функций, кто отвечает за сохранение и восстановление регистров.
Впрочем, на асме вы тоже были вынуждены выработать для себя какую-то calling convention, это экономит время.

Ну а то, про что я говорил - что код на других языках (тот же C/C++) порой приходится отлаживать в виде асма - что требует некоторого знания асма для данной платформы (до сих пор не пойму, почему для x86 образовались два совершенно разных диалекта - собственно intel и gnu).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 06 июл 2017, 12:11 
Старожил

Зарегистрирован: 17 сен 2013, 13:53
Сообщения: 3132
Alexandr_1 писал(а):
Про calling conventions даже не слышал, посмотрел по интернету. Наверно, при вызове функции у себя действую по-другому. При вызове функции регистры РОН (это AVR), используемые в этой функции, забрасываю в стек, по завершении функции возвращаю. А аргументы передаю через SRAM.


"Г-н Журден: Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой."(С)Мольер :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 06 июл 2017, 13:18 
Старожил

Зарегистрирован: 25 авг 2011, 14:00
Сообщения: 2684
Alexandr_1 писал(а):
Когда при отладке в реальном режиме времени можно, практически, в любом месте просмотреть любую переменную, всё резко упрощается.
До тех пор пока не надо отладить любой коммуникационный протокол с таймаутом или механику быстрее черепахи. Тогда оказывается что в реальном времени ничего посмотреть нельзя, ибо вся программа ломается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 06 июл 2017, 23:57 
Старожил
Аватара пользователя

Зарегистрирован: 26 янв 2010, 21:48
Сообщения: 3718
Откуда: Звенигород
А ещё встречается фигня, что отладчик сбрасывает флаги при пошаговом выполнении. Это к флагам, которые сбрасываются при чтении регистров. Я с этим, в своё время, ещё на stm8 сталкивался, когда I2C использовал. При обычной работе все хорошо, а при пошаговой висло на первой же проверки установки флага.

_________________
От Парижа до Находки с водкой лучше, чем без водки!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 07 июл 2017, 15:22 
Старожил
Аватара пользователя

Зарегистрирован: 03 сен 2010, 22:46
Сообщения: 5423
Откуда: Москва
Для отладки в реальном времени нужен трассировщик, штука в наших краях редкая, хотя и очень полезная в таких случаях. Но это имеет мало отношения к архитектурам, те или иные возможности для трассировки есть почти во всех, и уж тем более во всех кортексах (встроено в ядро).

Отправлено с моего SM-N920C через Tapatalk


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 07 июл 2017, 16:13 
Старожил

Зарегистрирован: 25 авг 2011, 14:00
Сообщения: 2684
В упомянутых Атмегах - только ногодрыг свободными пинами, если они есть, и логический анализатор. В старших кортексах MTB тоже нету, и не знаю какие из бесплатных дебаггеров его поддерживают. Поэтому если есть комм. стеки то хорошо иметь ОСРВ с отдельной задачей дебага-логгинга и дополнительным контролем временных интервалов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 02:35 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 393
aamonster писал(а):
Calling conventions - это в основном для языков высокого уровня. Как передаются аргументы и результаты функций, кто отвечает за сохранение и восстановление регистров.
Впрочем, на асме вы тоже были вынуждены выработать для себя какую-то calling convention, это экономит время.

Конечно, пришлось делать свою calling convention (теперь буду знать, как это называется).
Похоже, передача через стек гораздо лучше, так что буду отрабатывать этот вариант.
Когда-то выбрал передачу через SRAM, в этом случае можно вызывать функцию из любого места программы, не заботясь о регистрах и т.д.
Передача через стек будет быстрее, почему-то не сообразил про такой вариант.
count_enable писал(а):
Alexandr_1 писал(а):
Когда при отладке в реальном режиме времени можно, практически, в любом месте просмотреть любую переменную, всё резко упрощается.
До тех пор пока не надо отладить любой коммуникационный протокол с таймаутом или механику быстрее черепахи. Тогда оказывается что в реальном времени ничего посмотреть нельзя, ибо вся программа ломается.

Не так всё плохо.
При отладке использую программную передачу одного байта в дебаггер через свободные выводы. В дебаггере свой МК, который обеспечивает отладку и программирование.
По времени это не так много, вроде как менее 150 тактов отлаживаемого МК.
Задержка небольшая, так что во многих местах программы можно посмотреть без проблем. Но, конечно, бывали случаи, когда даже такая задержка «ломала» программу.
Если всё же очень хочется в таком месте посмотреть переменную, то это можно сделать. Достаточно переменную «сбросить» в регистры РОН (это АВР), это займёт всего несколько тактов, а затем переменную посмотреть в другом месте программы, где нет «напряга» со временем.
Приходилось делать обмен данными (SPI, RS232), особых проблем с отладкой не было, хотя иногда приходилось придумывать специфические приёмы применения дебаггера.
akatenev писал(а):
Для отладки в реальном времени нужен трассировщик, штука в наших краях редкая, хотя и очень полезная в таких случаях. Но это имеет мало отношения к архитектурам, те или иные возможности для трассировки есть почти во всех, и уж тем более во всех кортексах (встроено в ядро).

Не знаю, что собой представляет трассировщик для макроассемблера, чем он лучше просмотра переменных с помощью дебаггера.
Скажем, в одном месте программы мне надо посмотреть переменную «а», в другом – «b». В этих местах программы поставил команды: Q (N1, a) и
Q (N2,b). N1 и N2 – маркеры точек программы. После программирования на экране компьютера появится:
N1 a
N2 b
Здесь a и b – конкретные числа.
Так можно просмотреть путь прохождения программы и переменные в нужных точках программы. Есть, конечно, выше указанное ограничение по времени, здесь ситуация похуже, приходится передавать ещё и маркерный байт, но, в большинстве случаев, это малосущественно.
В «напряженные» по времени точки программы лучше без особой нужды не «соваться».
count_enable писал(а):
В упомянутых Атмегах - только ногодрыг свободными пинами, если они есть, и логический анализатор. В старших кортексах MTB тоже нету, и не знаю какие из бесплатных дебаггеров его поддерживают.

«… если они есть…» - фраза мало подходит разработчику.
В большинстве случаев разработчик сам выбирает МК, поэтому он должен выбрать МК побольше, чтобы свободные пины были. Свободные пины могут пригодиться и в дальнейшем при развитии проекта.
Кстати, много пинов для дебаггера не надо. У дебаггера два сигнала: тактовый сигнал C и сигнал данных D. Запись данных в дебаггер идёт по сигналу С, поэтому под сигнал D можно использовать и занятый пин, лишь бы он был «на выход». Для сигнала С также можно использовать занятый пин, если на время отладки его можно выключить в программе (например, пин используется для зажигания несущественного светодиода и т.д.).
В принципе, для сигнала С можно использовать и занятый пин без отключения в программе, но тут надо аккуратнее.
count_enable писал(а):
Поэтому если есть комм. стеки то хорошо иметь ОСРВ с отдельной задачей дебага-логгинга и дополнительным контролем временных интервалов.

В макроассемблере с помощью дебаггера в реальном времени можно без ОСРВ измерять временные интервалы с точностью до долей микросекунд.
Достаточно в программе поставить команды старта и стопа. Эти команды – простой переброс сигнала пина, поэтому их можно использовать, практически, без ограничения в любом месте программы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 06:55 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
Alexandr_1 писал(а):
Похоже, передача через стек гораздо лучше, так что буду отрабатывать этот вариант.
Когда-то выбрал передачу через SRAM, в этом случае можно вызывать функцию из любого места программы, не заботясь о регистрах и т.д.
Передача через стек будет быстрее, почему-то не сообразил про такой вариант.

А почему передача через стек будет лучше и быстрее?
Мне кажется, что в идеале проще, надежнее и быстрее иметь все переменные глобальными (с ограничением области видимости). Отказаться от манипуляций с указателем стека и возможных проблем с выходом за пределы стека.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 11:02 
Старожил
Аватара пользователя

Зарегистрирован: 26 янв 2010, 21:48
Сообщения: 3718
Откуда: Звенигород
А gcc и не знает)))) Они передают параметры через регистры, по возможности))))

_________________
От Парижа до Находки с водкой лучше, чем без водки!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 14:43 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
bw429 писал(а):
Мне кажется, что в идеале проще, надежнее и быстрее иметь все переменные глобальными

Надежнее в каких случаях? Ассемблер?

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 14:57 
Старожил
Аватара пользователя

Зарегистрирован: 03 сен 2010, 22:46
Сообщения: 5423
Откуда: Москва
Трассировщик - это не для ассемблера, он вообще не имеет отношения к языкам программирования. Трассировщик позволяет отслеживать выполнение программы в реальном времени, иногда это очень важно, потому что многие интересующие события происходят именно в реальном времени. Трассировщики дорогие, поддерживаются в основном только коммерческими тулчейнами. В случае с ARM поддержка трассировки встроена в ядро кортексов, называется ETM.

Изображение
Изображение

Иногда нужна только трассировка данных, это гораздо проще, делается в случае ARM через SWO. Этот способ поддерживают очень многие дебаггеры.

Если интересно: https://www.terraelectronica.ru/news_company.php?ID=569


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 15:02 
Старожил
Аватара пользователя

Зарегистрирован: 03 сен 2010, 22:46
Сообщения: 5423
Откуда: Москва
count_enable писал(а):
В старших кортексах MTB тоже нету, и не знаю какие из бесплатных дебаггеров его поддерживают.

В кортексах как раз есть, в ARMv7 и ARMv9 нет, но это и не кортексы. У старших ядер слишком высокая производительность, встроить трассировку сложно, и трассировщик получится очень дорогой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 10 июл 2017, 15:33 
Старожил

Зарегистрирован: 25 авг 2011, 14:00
Сообщения: 2684
Я имел в виду старшые по возрасту :). ЕМНИП МТВ появился в Кортехе-М0 только в поколении "М0+".
Обидно что китайцы еще не освоили копирование трассировщиков. Но т.к. китайцы вообще не умеют в софт то ждать бесплатной иде с поддержкой трассировки еще долго.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 11 июл 2017, 05:24 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
elisey писал(а):
bw429 писал(а):
Мне кажется, что в идеале проще, надежнее и быстрее иметь все переменные глобальными

Надежнее в каких случаях? Ассемблер?

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

PS: еще интересно, можно ли заменить стек возвратов эдаким заранее построенным деревом возвратов? Т.е. полностью отказаться от устаревшей технологии стеков :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 11 июл 2017, 11:10 
Старожил

Зарегистрирован: 19 мар 2013, 19:37
Сообщения: 2447
Откуда: Санкт-Петербург
bw429 писал(а):
Можно предположить, что использование стека для данных придумали в те времена, когда память стоила дорого и ее было мало.

Довольно забавно читать гипотезы человека, который в теме ни в зуб ногой :-).
1. Рекурсия. Передайте параметры через глобальные переменные, ага-ага.
2. 100500 функций. Заведёте 100500*n переменных или будете использовать одни и те же? Если одни и те же - где будете сохранять старое значение переменной, когда она понадобится для "внутренней" функции? Учтите, что внешняя и внутренняя функция могут быть в разных модулях - т.е. компилиться по отдельности, не зная в этот момент друг о друге.

В общем, геморроя много, толку мало (а на современных процах - вообще может быть вред от cache misses).

Впрочем, я знаю один компилятор паскаля, который таки передавал через переменные в фиксированных адресах RAM. Дело было под CP/M-80, и рекурсия в этом компиляторе по умолчанию была запрещена.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 11 июл 2017, 14:36 
Старожил

Зарегистрирован: 17 сен 2013, 13:53
Сообщения: 3132
aamonster писал(а):
Довольно забавно читать гипотезы человека, который в теме ни в зуб ногой :-).
1. Рекурсия. Передайте параметры через глобальные переменные, ага-ага.


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

aamonster писал(а):
2. 100500 функций. Заведёте 100500*n переменных или будете использовать одни и те же? Если одни и те же - где будете сохранять старое значение переменной, когда она понадобится для "внутренней" функции? Учтите, что внешняя и внутренняя функция могут быть в разных модулях - т.е. компилиться по отдельности, не зная в этот момент друг о друге.

В общем, геморроя много, толку мало (а на современных процах - вообще может быть вред от cache misses).


Использование регистров для передачи тоже имеет те же недостатки, но все же используется.
Тут хуже что велосипед понятен только тому, кто его собрал, а прочим уже неясно, что куда передается и почему такие вот пляски с бубном. Хотя если кто помнит, то даже при передаче через стек есть поле для маневра, типа кто очищает стек и порядок передачи переменных :)

aamonster писал(а):
Впрочем, я знаю один компилятор паскаля, который таки передавал через переменные в фиксированных адресах RAM. Дело было под CP/M-80, и рекурсия в этом компиляторе по умолчанию была запрещена.


Там просто памяти мало было и компайлер не шибко интеллектуальный, чтобы рекурсию в цикл развернуть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 11 июл 2017, 15:24 
Старожил

Зарегистрирован: 19 мар 2013, 19:37
Сообщения: 2447
Откуда: Санкт-Петербург
fr0ster, ну да, в ту эпоху с оптимизирующими компиляторами было не особо... Плюс проц 8080 - у него не особо много режимов адресации, и заточенного под использование стек фреймов (типа ADD AX,[BP+07]) тупо нету.

Кстати, в том компиляторе, если пометить функцию, как рекурсивную - насколько я помню, он реализовывал перекладывание переменных в стек (т.е. проседала производительность)

А "рекурсию в цикл развернуть" - разверните обход дерева, когда при обработке узла есть свои переменные, нужные и до, и после обработки children. Получите аккурат стек - и, как вы понимаете, делать второй стек параллельно со стеком вызовов в большинстве случаев будет куда хуже, чем пихать всё в стек вызовов.

Передача через регистры - самый быстрый путь, вот за него и цепляются. Через стек - самый тупой и всегда работающий. Через "статические переменные" - ни то ни сё, использовавшееся от безысходности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 11 июл 2017, 16:40 
Старожил

Зарегистрирован: 17 сен 2013, 13:53
Сообщения: 3132
aamonster писал(а):
А "рекурсию в цикл развернуть" - разверните обход дерева, когда при обработке узла есть свои переменные, нужные и до, и после обработки children. Получите аккурат стек - и, как вы понимаете, делать второй стек параллельно со стеком вызовов в большинстве случаев будет куда хуже, чем пихать всё в стек вызовов.


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

aamonster писал(а):
Передача через регистры - самый быстрый путь, вот за него и цепляются. Через стек - самый тупой и всегда работающий. Через "статические переменные" - ни то ни сё, использовавшееся от безысходности.


Ну стек это не только ценный мех, а еще и компромис между производительностью и безопасностью.
Либо анально огораживаете стек и тратите процессорное время на проверку, что у вас переполнение стека не выполнит какой нить эксплойт, либо имеете лоторею.. но правда вряд ли кто эксплойт для тиньки будет использовать :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 12 июл 2017, 06:40 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
fr0ster писал(а):
Либо анально огораживаете стек и тратите процессорное время на проверку, что у вас переполнение стека не выполнит какой нить эксплойт, либо имеете лоторею.. но правда вряд ли кто эксплойт для тиньки будет использовать :)

А если не эксплойт, а просто размер стека неправильно задан. Например, иар для авр не умеет во время компиляции определять макс размер стека.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 12 июл 2017, 06:43 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
aamonster писал(а):
Получите аккурат стек - и, как вы понимаете, делать второй стек параллельно со стеком вызовов в большинстве случаев будет куда хуже, чем пихать всё в стек вызовов.

А вот у иар для авр как раз два стека - вызовов и переменных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 12 июл 2017, 06:47 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
aamonster писал(а):
1. Рекурсия. Передайте параметры через глобальные переменные, ага-ага.
2. 100500 функций. Заведёте 100500*n переменных или будете использовать одни и те же? Если одни и те же - где будете сохранять старое значение переменной, когда она понадобится для "внутренней" функции? Учтите, что внешняя и внутренняя функция могут быть в разных модулях - т.е. компилиться по отдельности, не зная в этот момент друг о друге.

100-500 функций это не так уж много переменных. Грубо говоря, несколько кБайт - практически несущественная величина.

А вот все-таки, если рассматривать с точки зрения упрощения компилятора и повышения надежности, что все таки будет лучше?

Существуют ли компиляторы, которые постоянно контролируют стек от переполнения? И на этапе компиляции автоматически определяют размер стека (или стеков)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32 vs all other
СообщениеДобавлено: 12 июл 2017, 10:33 
Старожил

Зарегистрирован: 17 сен 2013, 13:53
Сообщения: 3132
bw429 писал(а):
Существуют ли компиляторы, которые постоянно контролируют стек от переполнения? И на этапе компиляции автоматически определяют размер стека (или стеков)?


Да. Нет.
Первое реализуется прописыванием некоего кода между кадрами стека и проверкой этого кода после возврата из функции, не сошлось, генерится ошибка насчет порчи стека. А второе фантастика пока, слишком много потребуется знать компилятору, что бы подобное реализовать. ИМХО. Хотя могу и ошибаться.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 352 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB