Да, разложение Фурье сигнала с АЦП (на частоте около 16 кГц) для ATMega8 я писал на C. Однако моментально напоролся на желание компилятора сохранять все РОН при входе в прерывания, из-за чего 16 кГц превратились в примерно 9. Желание было выявлено путем анализа ассемблерного листинга, компилятору была выписана строгая директива больше так не делать, проект был сдан.
Владение инструментом как раз и требует знания внутренней кухни компилятора вплоть до ассемблера.
В случае же с мелким контроллером без ОЗУ, GCC умывает руки:
Студия замечательна тем, что содержит прекрасный симулятор/отладчик, с встроенным справочником по регистрам и периферии контроллера. То есть многие вопросы можно решить, глядя на подсказки студии, без зарывания в даташит.
С Эклипс другая проблема — я для разработки долгое время использовал старинный Dell Latitude CPx (только из-за наличия на нем более чем удобного для электронщика LPT)
(он засветился в одном из эпизодов Секретных материалов).
Так вот, этот прекрасный старикан просто не тянул столь прожорливую IDE, а с четвертой студией — справлялся.
Предлагаю спуститься с теоретических небес на практическую землю:
Утверждение: Единственная программа на компьютере, которая никогда не останавливается — операционная система (в том числе и драйверы, системные службы и так далее).
Критерий остановки всех этих компонент — отключение компьютера. Что логично, так как операционная система и системное ПО как раз и нужны для работы компьютера.
Прикладные же программы устроены так, что непременно завершатся:
-это может произойти по независящим от автора прикладной программы причинам (если с системными сигналами еще можно поспорить, то с вынутым штепселем — увы).
-все прочие причины находятся под контролем автора программы. Критерий корректности такой программы предлагает Дейкстра в своей работе. Коротко он формулируется так — работа прикладной программы должна завершиться решением прикладной задачи, либо сообщением с описанием причин, почему задача не была решена.
Согласитесь, что навечно зависающая программа бесполезна как минимум?
Даже те ситуации, когда зацикливание неизбежно и выход из цикла зависит только от входных данных, которые априорно проверить невозможно (тут теорема Геделя о неполноте высовывается), будут охвачены сторожевым счетчиком «разумного числа итераций», исчерпание которого будет приводить к остановке программы с ошибкой.
У меня как раз получилось все скачать с официального сайта — меня лишь попросили заполнить небольшую форму и верифицировали почту, прислав ссылку. После этого я смог скачать и шестую, и четвертую версии студии.
не может существовать даже алгоритма, который генерирует минималтную программу, просто выводящую заданную строку.
Далее, вы утверждаете:
Строку, очевидно, не наперёд заданную.
Близость к теоретической информатике (и любой другой сильной теории) требует в первую очередь ясного и последовательного изложения идей и результатов размышлений.
Тьюринг показал, что не существует общего алгоритма решения проблемы остановки. Из этого следует, что если наложить на программу и данные дополнительные ограничения, проблема становится вполне разрешимой.
В частности, если мы имеем граф потока управления, и он не содержит циклов, или эквивалентными преобразованиями сводится к графу без циклов, то очевидно, что для данной программы мы сразу можем сказать — она завершится.
не может существовать даже алгоритма, который генерирует минималтную программу, просто выводящую заданную строку.
— прекрасный результат слепого применения теории: во первых, выглядит абсурдно, во — вторых, легко опровергается — делаем железку с одной инструкцией — «печатай эту самую строку», тогда программа будет состоять из одной этой инструкции.
Интуитивно чувствуется, что здесь палки в колеса поставит или упомянутая вами теорема с громким именем, или теорема Геделя о неполноте. Однако быть может имеет смысл поискать условия, при которых поиск всех эквивалентных программ сведется к перебору?
Уже при использовании языка высокого уровня приходится либо обкладываться документацией на компилятор, либо смотреть листинг, который этот компилятор сотворил. Иначе может оказаться так, что при входе в прерывание компилятор «на всякий случай» решит положить все 32 РОН на стек, что приведет к драматическому снижению скорости отклика на это прерывание.
Я бы не стал заявлять столь категорично — каждая конкретная задача требует своего инструмента.
Более важно то, что ассемблер ставит жирный крест на переносимости. Однако история x86 — яркий пример того, как вовремя установленные владельцами платформы подпорки позволяют спасти положение. Увы, ценой технологической красоты.
Форта не будет — стек реализован отдельно от регистров, в него можно поместить только три значения и этими значениями может быть только девятибитный указтатель инструкции (даташит, страница 9)
Разумеется, я с вами согласен, так как человекочас работы программиста стоит много дороже тактов и ячеек памяти. Однако есть еще на вскидку три области, где экономия на тактах актуальна — программирование для развлечения/обучения, встраиваемые системы для жестких условий (космос, роботы для ликвидации аварий на АЭС и подобное) и жесткое энергосбережение.
Замечание в сторону — отсутствием экономии на тактах несознательные граждане доводят Андроид до посадки батареи за полсуток.
Владение инструментом как раз и требует знания внутренней кухни компилятора вплоть до ассемблера.
В случае же с мелким контроллером без ОЗУ, GCC умывает руки:
С Эклипс другая проблема — я для разработки долгое время использовал старинный Dell Latitude CPx (только из-за наличия на нем более чем удобного для электронщика LPT)
(он засветился в одном из эпизодов Секретных материалов).
Так вот, этот прекрасный старикан просто не тянул столь прожорливую IDE, а с четвертой студией — справлялся.
Утверждение: Единственная программа на компьютере, которая никогда не останавливается — операционная система (в том числе и драйверы, системные службы и так далее).
Критерий остановки всех этих компонент — отключение компьютера. Что логично, так как операционная система и системное ПО как раз и нужны для работы компьютера.
Прикладные же программы устроены так, что непременно завершатся:
-это может произойти по независящим от автора прикладной программы причинам (если с системными сигналами еще можно поспорить, то с вынутым штепселем — увы).
-все прочие причины находятся под контролем автора программы. Критерий корректности такой программы предлагает Дейкстра в своей работе. Коротко он формулируется так — работа прикладной программы должна завершиться решением прикладной задачи, либо сообщением с описанием причин, почему задача не была решена.
Согласитесь, что навечно зависающая программа бесполезна как минимум?
Даже те ситуации, когда зацикливание неизбежно и выход из цикла зависит только от входных данных, которые априорно проверить невозможно (тут теорема Геделя о неполноте высовывается), будут охвачены сторожевым счетчиком «разумного числа итераций», исчерпание которого будет приводить к остановке программы с ошибкой.
Очень жаль, что Атмел отказалась от ATTiny15 — шестая студия о нем не знает, а фирма выпустила документ с рекомендациями о замене на ATTiny25
Далее, вы утверждаете:
Близость к теоретической информатике (и любой другой сильной теории) требует в первую очередь ясного и последовательного изложения идей и результатов размышлений.
Тьюринг показал, что не существует общего алгоритма решения проблемы остановки. Из этого следует, что если наложить на программу и данные дополнительные ограничения, проблема становится вполне разрешимой.
В частности, если мы имеем граф потока управления, и он не содержит циклов, или эквивалентными преобразованиями сводится к графу без циклов, то очевидно, что для данной программы мы сразу можем сказать — она завершится.
— прекрасный результат слепого применения теории: во первых, выглядит абсурдно, во — вторых, легко опровергается — делаем железку с одной инструкцией — «печатай эту самую строку», тогда программа будет состоять из одной этой инструкции.
Я бы не стал заявлять столь категорично — каждая конкретная задача требует своего инструмента.
Увы, на ассемблере труднее, следуя Кнуту, реализовывать грамотное программирование, но это расплата за тотальный контроль над оборудованием.
Более важно то, что ассемблер ставит жирный крест на переносимости. Однако история x86 — яркий пример того, как вовремя установленные владельцами платформы подпорки позволяют спасти положение. Увы, ценой технологической красоты.
Замечание в сторону — отсутствием экономии на тактах несознательные граждане доводят Андроид до посадки батареи за полсуток.