ИМХО неправильно это....
------------------------
а вот ещё на тему стека ))
в одном случае есть переполнение, в другом нет!
это я как бывший программер, в т.ч. на языке "Форт" (там все операции делаются со стеком)
понял "заочно", что скорее всего есть такая "фича"
(думал, пока ехал в транспорте, а ща проэкспериментировал, и убедился в своей правоте)
Последний раз редактировалось AI!; 13.03.2011 в 22:55.
Анатолий, вы видимо меня не так поняли....
я привёл свои примеры не для того, чтобы поругать разработчиков ПР и/или само ПР....
а чтобы (НА)толкнуть на способы решения проблемы с глубиной стека!
если внимательно посмотреть на примеры, то видно, что из одного легко можно сделать другой...
так вот - почему бы эту задачу не переложить на "компилятор"?!
(процедура подготовки кода перед записью в ПР)
понимаю, что текущая реализация многих элементов скорее всего не допускает изменение порядка вычислений параметров,
НО есть же коммутативные операции (!!!), и если компилятор поменяет местами операнды этой операции, то ВОЗМОЖНО уменьшится глубина потребляемого стека!!!
т.е. есть способ частичного решения проблемы со стеком "малой кровью" ))
не перекладывая эту проблему на НАЧИНАЮЩЕГО пользователя ))
PS надеюсь после столь развёрнутого "размышления вслух", разработчики меня поймут правильно, и согласятся со мной
Последний раз редактировалось AI!; 14.03.2011 в 00:26.
А ни кто и не ругает .Просто дважды пришлось обрушивать стек (6,15) при решении конкретных задач .Просто разработчики не предполагали вначале ,что мы будем такие задачи возлагать на ПР ,поэтому и поскромнечали .Просьбу мою сделать стек глубиной 32, зарубили, на все случаи .Да ладно ,вот и вы вовремя подошли с целочисленной логикой ,прорвемся.
Да, Анатолий, всё Вы правильно говорите. Только просто увеличивая значение стека, его надолго всё равно не хватит.Сообщение от rovki
Есть одна идея на будущее - сделать глубину стека динамическим параметром. Как вернемся к этой теме - осуществим.
Последний раз редактировалось Евстигнеев Максим; 14.03.2011 в 10:00.
ещё пожелания по модернизации программы
1) сделать у ФБ SHL/SHR/Extract/PutBit параметр N такой же как у CT/CTN/CTU
т.е. задаваемый с помощью окна "сва-ва",а не с помощью константы
(связь всегда можно будет сделать с помощью "wr2fb")
2) сделать блок write2fb визуально понятным, таким каким он становится при переходе в режим симулятора
(т.е. с чем он связан было понятно без тыканья на него)
Насчет 1 пункта действительно под вопросом... Но как заметил rovki не только из-за того приверженцем кого является компания ОВЕН. )))) Дело в том, что целесообразность данного действия под вопросом, а реально это затронет как программу OWEN Logic, так и саму прошивку, причем правкой "не одной строки кода" если можно так выразиться. )))) Если в этом действительно будет большая необходимость, то тогда будет другой разговор. Но за высказывание ПОЖЕЛАНИЙ большое спасибо!!!
Насчет 2 пункта, то я подумаю над увеличением информативности данного блока.
насколько я понимаю, изменится только способ отображение ФБ, а не его суть!
ИМХО имеет смысл переносить параметры в поле "св-ва", если этот параметр чаще задаётся как константа...
а у меня пока это именно так...
(статистику могу судить пока только по себе)
вот где действительно возникнет проблема - так это совместимость версий при открытии старых проектов...
но вроде и тут есть опыт (напр. старый & перерос в новый AND, но в старых проектах открывается по старому)
PS ответ принят, всё выше сказанное просто мысли вслух...
Навряд ли сделают(1) ,потому так сделано в кодесис ,а овен приверженец МЭК.
На сайте на странице прибора в разделе "Программное обеспечение beta" доступна для скачивания новая версия OwenLogic. В ней исправлены ошибки с целочисленными операциями и добавлена возможность выбора формата отображения чисел.
Требует смены прошивки. Её можете скачать там же.
http://www.owen.ru/catalog/72837766
Ваши права
Ответить с цитированием